這篇文章是「嘗試不同數據存儲 Advent Calendar 2019」的第10天文章。
https://qiita.com/advent-calendar/2019/datastores

从以“触摸为主题的附件 日历”这个角度来看，也许会有些偏离，但是这次我想说，如果在“触摸之前”先读它，会非常好，或者说，我更希望早点遇到这本书！！
关于“数据驱动应用设计”，链接如下：

我想把我的经验和想法融入其中，毫无顾忌地写下一切。

数据存储和我

首先，我要根据我的经历来谈一下为什么要写这样的事情。

遇见了HBase

大约三年前我转职至现任岗位之前，一直参与了以关系型数据库管理系统（RDBMS）作为永久存储的系统开发。然而，在我转职至现任岗位时，决定采用HBase作为存储系统。当我听到这个消息时，我本能地想到“难道不能用RDB进行分片吗？”。此外，谈及当前的职务，这也是人们经常问及的一个点，可能也有很多人有着类似的感受。

虽然怀抱着一些疑惑，但考虑到事情已经决定了，我开始阅读了封面上有O’reilly中文版HBase的那本有点厚的书。

http://shop.oreilly.com/product/0636920014348.do

在书的开头部分，有如下描述：

問題是，為了性能而牺牲(RDBMS的)关系功能是否是明智之举。通过将数据模型非规范化，尽量减少不可避的锁定，可以避免等待和死锁问题。水平扩展的可伸缩性一直内置于系统中，无需进行重分区，即使数据增长也不用担心。最后，如果我们希望实现与可伸缩性相同的机制，以获取容错性和数据可用性，那就需要使用NoSQL的解决方案。

HBase：权威指南中的“1.3.2 抽取自可扩展性”（括号内为我的背景说明）

看完这段文章后，确实有一些道理。实际上，我发觉自己成为了一个只会用“分区不就好了吗？”这样的借口来回避未知事物的无用工程师。即使提出替代方案，我也感到需要更加认真地学习。这是我一个重要的经验教训。

（根据情况而定，如果团队已经有了擅长MySQL的人，选择在关系型数据库中进行分区可能是合理的选择，并不是说NoSQL产品在所有情况下都更好。）

与各种其他数据存储的相遇 (Yu ge zhong qi ta shu ju cun chu de xiang yu)

最近，我有机会在生产环境中验证和运行各种类型的数据存储，从HBase开始，到Kafka，AWS的Dynamo DB，Elasticsearch等。最近，我有机会学习Elasticsearch，它是一个键值存储的HBase和全文搜索引擎的完全不同的中间件。但是，我开始意识到，尽管这两个产品具有完全不同的用途，但我在脑海中会将Elasticsearch的merge与HBase的compaction相对应，或者在HBase中，region数量会持续增加，而在Elasticsearch中，必须首先固定分区数量这一点有些不方便。尽管如此，我还是发现了许多相似的比较点，这是非常有趣的！

并且，在其他数据存储方面，每个单独的存储方式都有各种各样的优点和缺点。之前我一直在学习各个单独数据存储的机制，但是如果将其抽象成”(分布式)数据存储”，就可以理解它具有的通用要点，并且可以更快地理解每个产品的区别，当查看总体上都是写得很好的官方文档或其他产品的比较表时，也能够快速洞察其中的权衡。我开始意识到这一点，并随之逐渐改变了物事的看法。
（注：对于专门学习该领域的人来说，这可能是一个太过常识的点，但对于我这样完全从零开始的人来说，这个发现是相当新颖的?）

当前的数据存储情况

公有云、软件即服务（SaaS）等

2021年底时，公共云/相关Saas的发展势头迅猛，预计势头还将持续下去。与此同时，数据存储相关的托管服务类型也在不断增加（其中可能有些服务已过时，有些服务正在流行）。
在能够使用这种环境的系统中，除非已经具备了丰富的专业团队，否则在许多情况下使用这种托管服务都是合理的。实际上，负责运营数据存储的人员逐渐减少（严格来说，Iaas和Saas的角色分工发展，运营人员在企业层面逐渐被隐藏起来）是不是这样呢？

因此，即使不了解细节操作的技巧（例如备份、容错/实例故障时的替换方法等），也能够在没有重大事故的情况下，成功进行各种数据存储的操作。

选择数据存储和数据建模

通过这种发展，关于数据存储，是否不需要了解任何东西呢？对此，还没有达到那个程度，仍然需要用户在使用哪种数据存储和采用什么数据模型方面做出决策。

（如果问每个公共云的解决方案架构师，可能会得到类似的答案，但最终还是要根据贵公司的服务预计流量和工作负载特性来决定…嗯，这样说也没错，但我们需要的是明确的答案！有时候会出现我们想要的答案不明确的情况。）

采用存储数据有限的规模扩展（主要是关系型数据库）时，一旦出现瓶颈，就可能成为业务本身的瓶颈（非常令人担忧）。然而，支持规模扩展的数据存储（主要是NoSQL系列），虽然具有规模扩展的特性，但与仅使用关系型数据库相比，有很多不同的特点，这些方面的知识并不像基于关系型数据库的系统那样普遍。对于 eventual consistency 等概念，人的大脑很难一直意识到，使用（仅）关系型数据库时不会遇到的麻烦错误也可能会遇到。如果服务规模并不是特别大的时候，只使用简单的关系型数据库反而可能会使工作变得更加繁重。

最終结果是根据我们公司服务的流量和工作负载特性决定的，包括不断涌现的新物品，在充分了解各个数据存储的特性的基础上，能够根据服务状况选择合适的物品，并且继续适应变化，有时还需要考虑迁移计划…作为一名工程师，我最近强烈感到需要具备这样的能力。

数据驱动应用程序设计

总结到这里，

• 色んなデータストレージを個別に学ぶのではなく、１つ抽象度を上げて効率的に学びつつ、新しく出てくるモノの特徴もしっかりと抑えれるようになりたい、という知識的な所での興味

様々な種類のデータストレージが出てくる中で、それを適切に選択し、データモデリングが出来ることは、まだまだエンジニアとしての重要なスキルになりそうという実利的な所での興味

从这两点出发，有没有一种方法可以扎实地学习这方面的知识呢~ 而我正为此感到困惑不解。然后我偶然找到了《数据驱动应用设计》，这本书真是我一直在找的，我为什么不早点遇到它呢~ 完全符合我的需求。

由于篇幅有些长，本次就到这里吧。在12月17日计划中的”第二部分”中，我将写下我从这本书中具体学到了什么。敬请期待！