データはアーキテクチャの中心です
インターネット業界のアーキテクトとして、ほぼ毎日、さまざまなタイプのデータ、つまり長年の経験、さまざまな業界、さまざまなシステムを、技術レベルから抽象的なものまで、1文に要約して扱います。
データはアーキテクチャの中心です。
あなたがそれについて考えるならば、私たちが実際に行うすべての仕事はデータを中心に展開します。データの生成、データのストレージ、データの消費、データのフロー...さまざまなニーズに応じてデータの形式とサービスを変更するだけです。コンピュータ部門の学生は、教師が言った文をまだ覚えているかもしれません：プログラム=アルゴリズム+データ構造私はこの文を大胆に模倣しています：システム=ビジネスロジックxデータ。一般的な「煙突システム」の問題、特にデータアイランドの問題など、多くのアーキテクチャ上の問題はデータ層が原因であると言えますが、本質的な理由はデータ層がクリアされていないためです。構造について考えると、「頭痛、頭、足、足」になる可能性があり、長い時間を費やすのは面倒です。逆に、データレイヤーが適切に管理されている場合は、「2つのガバナー」を開くようなもので、4ポンドまたは2ポンドの効果があります。 。
しかし、理想は通常完全ですが、現実は非常に細いです。少なくとも5年前に起業したときは、データの問題をうまく解決できるシステムはないと感じました。おそらく好奇心の強い読者はこう尋ねるでしょう：Hadoopはありますか？そしてNoSQL？リレーショナルデータベースをライブラリとテーブルに分割できるかどうかは関係ありません。実際、これらは、その年のストレージの問題に対処するためのほぼすべての候補であり、これらのソリューションの共通の特徴は次のとおりです。
具体的には、これらのソリューションはデータアプリケーションシナリオにはそれほど大きくありません。より複雑なサービスの場合、カバレッジを完了するためにn個の複数のソリューションを同時に使用する必要がある場合があります。近年のインターネットサービスの複雑化に伴い、Kafkaなどのデータパイプラインの人気がますます高まっています。データガバナンスの観点から、それらは実際によく理解されています。さまざまなデータプラットフォームが独自の目的を担っています。完全にカバーするには、「島」の間に道路を建設する必要があります。
統一されたインターフェースで、できるだけ多くのシーンをカバーできるシステムができるかと考えていました。
真実の単一の情報源が必要です。データはアプリケーションロジックの隅々まで実行する必要があります。私の理想的なシステムでは、すべてのデータへのアクセスを制限しないでください（最初に権限とセキュリティを考慮しないでください。これは別の問題です）。たとえば、「制限」はより広範です。たとえば、十分な物理リソースがある限り、容量の上限はありません。システムは無制限に拡張できます。アクセスモデルの制限はありません。データを自由に関連付けて集計できます。一貫性の制限はありません。操作とメンテナンスはほとんどありません。人間の介入は必要ありません...
統合データベースとして分散データベースを使用するアーキテクチャ
私は特にアメリカのドラマ「Person of Interest（容疑者追跡）」に魅了されました。このTVシリーズには、神のような人工知能、The Machineがあり、すべてのデータを収集して分析し、将来の人々の行動を予測または介入します。このアメリカのドラマはまだ英雄のよりオーソドックスなテーマですが、私をもっと魅了するものは何ですか？The Machineをデザインできますか？私はこれまでAIの専門家ではありませんでしたが、The Machineのデータベースを設計することは現実的だと思われます。近年の起業の過程で、次のようなエキサイティングなポイントがあることがわかりました。
分散データベースを統合された中央アーキテクチャとして使用することが可能です。
これを理解するには？たとえば、上記の分割によって引き起こされる問題と同様に、データレイヤーの断片化は、ビジネスレイヤーを構成するためにより複雑にする必要があることを必然的に意味します。実際、多くのエンジニアは、システムの維持について考えるために線形思考を使用することを実際に好みます。コスト。しかし、実際の経験では、これは当てはまりません。データベースが1つとデータベースが10個しかないシステムの複雑さは、実際には単純な10倍ではありません。データの流れを考えると、メンテナンスコストはそれ以上になり得ます。
分散データベース中心のアーキテクチャはどのようなものですか？アーキテクチャ全体の中心は、十分なシーンカバレッジと無制限の水平スケーラビリティを備えたストレージシステムであることを理解するのは簡単です。ほとんどのデータフローはこのデータベースに制限されているため、アプリケーションレイヤーはほとんどステートレスになる可能性があります。この中央データベースはほとんどの状態を担当するため、各アプリケーションは独自のキャッシュによって高速化できます。ここで思い出したいのは、制限された拡張能力も分割の重要な理由であるため、上記の水平拡張能力を強調する理由です。未来を正確に予測する方法はこれまでありませんでした。1年たってもビジネスの変化を想像することは困難です（流行を考えてみてください）。
もう1つのよくある質問として、なぜキャッシュレイヤーをビジネスレイヤーに近づける必要があるのか、または中心にある巨大なデータベースがキャッシングの責任を負うべきでないのかを強調する必要があるのでしょうか。私の理解は、ビジネスだけがビジネスをよりよく理解し、データをキャッシュするためにどの戦略を使用する必要があるかを知っており、パフォーマンス（低レイテンシ）を考慮すると、キャッシュがビジネスに近いことは理にかなっています。
上記の文に対応して、「唯一の定数は変更である」、この構造の最大の利点は「定数で変更する」、またはより単純な言葉である簡潔です。グーグルは実際にはこの問題について非常に早い段階で考えました。
別の例はHTAPです。データベースの開発に注意を払う場合は、最近HTAPという用語に精通している必要があります。実際、私の考えではHTAPの本質は上記のカバレッジです。以下は典型的なアーキテクチャです。
従来のデータアーキテクチャは通常、OLTP、OLAP、オフラインのデータウェアハウスを分離し、各システムは独自の役割を果たし、独立したパイプライン（ETLを使用する場合もある）を介して同期されます。HTAPシステムは次のようになります。
表面的には、これはインターフェース層の単純な統合にすぎませんが、この意味は広範囲に及びます。最初に、データ同期の詳細は隠されています。これは、データベースレベルがそれ自体でデータを同期する方法を決定できることを意味します。 OLTPエンジンとOLAPエンジンは同じシステムにあるため、トランザクション処理など、同期プロセス中に多くの詳細が失われることはありません。つまり、内部分析エンジンは、従来のOLAPができないことを実行できます。 。さらに、ビジネスレイヤーを使用する場合、システムが1つ少なくなると、エクスペリエンスがより統一され、学習と変革のコストが削減されます。統合の力を過小評価しないでください。
未来はどこですか？
以上が過去5年間の出来事であり、創業時のアイディア通りに一歩一歩現実味を帯びてきましたが、今後5年間はどうなるのでしょうか？業界とテクノロジーへの理解が深まるにつれ、私が確信していることの少なくとも1つは次のとおりです。
柔軟なスケジューリングが将来のデータベースの中核機能になる
過去10年間のITテクノロジーの最大の変化がクラウドによってもたらされたことを誰も否定することはできません。この革命はまだ進行中です。クラウドのコア機能は何ですか？伸縮性があると思います。コンピューティングリソースの割り当ての粒度は、家を買うだけから家を借りるように変化するように、そしてホテルにとどまるのと同じくらい柔軟なものにさえ、ますますきめ細かくなっています。これはどういう意味ですか？本質は、「架空の」ビジネスピークに対して前払いする必要がないことです。
これまでは、サーバーを購入する場合でも、リースするキャビネットを購入する場合でも、事前に金額を設定する必要がありましたが、実際にピークのビジネスが届かなかったときには、これらの費用は事前に支払われていました。クラウドの出現により、弾力性がインフラストラクチャの基本的な機能に変わりました。データベースでも同じことが起こると思います。鄭州婦人科病院は良いです：http://www.xbhnzzyy.com/
多くの友人が疑問を抱いているかもしれませんが、ほとんどすべてのデータベースが透過的な水平方向の拡張をサポートしていると主張しているのではないでしょうか。実際、「フレキシブルスケジューリング」がスケーラビリティとして狭く理解されず、「スケジューリング」に焦点が当てられていることを願っています。理解を容易にするためにいくつか例を挙げましょう。
データベースはワークロードを自動的に識別し、ワークロードに応じて自動的にスケーリングできますか？たとえば、ピークが来ることを予測し、マシンを自動的に購入し、ホットデータのコピーをさらに作成してデータを再配布し、容量を事前に拡張します。事業ピーク後は、自動リサイクル機で減量します。
数据库能不能感知业务特点，根据访问特点决定分布？例如：如果数据带有明显的地理特征（比如，中国的用户大概率在中国访问，美国用户在美国），系统将自动的将数据的地理特征在不同的数据中心放置。
数据库能不能感知查询的类型和访问频度，从而自动决定不同类型数据的存储介质？例如：冷数据自动转移到 S3 之类比较便宜的存储，热数据放在高配的闪存上，而且冷热数据的交换完全是对业务方透明的。
这里提到的一切背后都依赖的是「弹性调度」能力。未来我相信物理资源的成本会持续的降低，计算资源的单价持续下降带来的结果是：当存储成本和计算资源变得不是问题的时候，问题就变成「如何高效的分配资源」。如果将高效分配作为目标的话，「能调度」就是显而易见的基础。 当然就像一切事物发展的客观规律一样，学会跑步之前，先要学会走路，我相信在接下来的一段时间内，我们会看到第一批初步拥有这样能力的新型数据库，让我们拭目以待。
下一个阶段是智能
对于更远的未来是怎么样子的？我不知道，但是就像 The Machine 一样，只有足够数据才能诞生出智能，我相信就像我们不了解宇宙和海洋一样，我们现在对于数据的认识一定是肤浅的，甚至大量的数据我们都还没记录下来，一定有更大奥秘隐藏在这海量的数据中，从数据中能获取什么样的洞察，能够怎么样更好的改变我们的生活，我并不知道，但是做这件事情的主角我猜不会是人类。虽然在这个小节我们讨论的东西可能就有点像科幻小说了，不过我愿意相信这样的未来，从数据的海洋中诞生出新的智能体。郑州试管婴儿费用：http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3100/
尾声
创业这五年的时间，回头看看那个最朴素的出发点：写一个更好的数据库彻底解决烦人的 MySQL 分库分表问题。似乎也算没有偏离初心，但是在这个旅途中一步步看到了更大的世界，也越来越有能力和信心将我们相信的东西变为现实：
我有一个梦想，未来的软件工程师不用再为维护数据库加班熬夜，各种数据相关的问题都将被数据库自动且妥善的处理；
我有一个梦想，未来我们对数据的处理将不再碎片化，任何业务系统都能够方便的存储和获取数据；
我有一个梦想，未来的我们在面临数据的洪流时候，能从容地以不变应万变。
最近我听到一句话，我个人很喜欢：雄心的一半是耐心。构建一个完美的数据库并不是一朝一夕的工作，但是我相信我们正走在正确的道路上。
凡所过往，皆为序章。