この記事では、最初のインターネット技術の生体内マイクロチャネル公共番号に登場
：リンクhttps://mp.weixin.qq.com/s/u1LrIBtY6wNVE9lzvKXWjA
著者：三の数十年を
この記事の目的は練習、進化と今後の展望生体内部ストレージの機能を紹介するために、より良いアイデアを誘致するための触媒としての役割を果たす。
まず、ニーズ分析
データを備え、より広く生体内のAI技術は、オフライントレーニング、オンライン見積り及び他のシーンのために重要な役割を果たしている、我々は信頼性の高い効率的なデータストレージの問題のさまざまな機能を解決するためにシステムを設計する必要があります。
特徴データの1特徴
（1）値ラージ
特徴データは、一般的に、圧縮されている場合でも、特に価値KVへの最終的な堆積物で、その結果、多くの分野が含まれています。
（2）データ記憶の大量、高並行性、ハイスループット
ここで大きくなるようにシーンを保存されたデータの量は、（例えばRedisのクラスタなど）KV-メモリは満たすことが難しいだけでなく、非常に高価です。かどうかは、オンラインまたはオフラインのシナリオのシーン、同時要求の大規模な量が、小さくはない値は、自然に大きなスループット。
（3）高い書き込み性能要件、低レイテンシー
最も特徴的なシーンは非常に低遅延の読み取りと書き込み、および継続的な安定性を必要とし、以下のジッタ。
（4）問い合わせの範囲を必要としません
シーンのほとんどは、ランダムのシングルポイントの読み取りと書き込みされています。
（5）充填マスデータのタイミング
データの多くの機能が、それはOLAP指向のストレージ製品の一部に存在しているときだけで計算され、定期的に一度カウントした、オンラインKVに時間同期における特徴データを回すことができるツールを持っていると思います。
使用の（6）容易
ストレージシステムにアクセスするサービスは、より良い理解コストのではありません。
2.潜在的な需要
-
大容量のストレージ要件の各シーンをサポートする、ユニバーサルディスクKVに拡張
私たちの目標は、海の星に、シーンの特性を満たすために限定されるものではない必要があります。
-
その他のサポートのNoSQL / Newsqlデータベース、資源の再利用
ビジネスニーズから始めて、我々はデータベース等、タイミングデータベース、オブジェクトストレージ、として、完全に隔離され、多種多様のNoSQLデータベースのニーズに続く場合は、各製品、無資源（コードプラットフォーム機能など）多重化、莫大な維持費です。
-
保守性
実装言語が小さすぎないまず第一に、それ以外の場合は、採用に困難なこと、そして私たちの技術開発・スタックの試合のベストを教えてくれます。
私たちは、運用・保守の複雑さを軽減するために設計されたサードパーティのサービスコンポーネントアーキテクチャにあまり依存することはできません。
3.氷山のストレージシステム
上記の需要に基づいて、我々は、ユーザーがRedisの同様のサービスの唯一のバージョンを参照して、互換性のRedisのプロトコルを決めたが、我々は、セキュリティの仕事の信頼性の背後に多くのことをやりました。
第二に、プログラム選択
プログラムの選択では、我々はいくつかの基本的な原則に従ってください。
-
オープンソースから、オンデマンド。
-
内国歳入、ブレーンストーミング。
-
言語の主流、主流のアーキテクチャ。
-
まず、信頼性、高いメンテナンス性。
簡単に言うには、長所と短所を分析し、当社の初期の研究プログラムのいくつかを説明します。
正直に言うと、研究は、優れたオープンソースのプロジェクトではありませんが、公式のコードや設計文書に依存している、何の深い経験、我々はオープンソース製品が私たちのために本当に適しているかを決定することは困難で、適切な較正方式の選挙戦はより良いかもしれませんタイプするだけでなく、ある程度、私たちの強力な実行を反映しています。
全体的に我々は、我々は最終的には、いくつかの時間後に理論研究と実践の後、既存の需要、潜在需要、使いやすさ、高度なアーキテクチャ、パフォーマンス、保守性のすべての面で最適なバランスを見つけることです星雲を選択します。
三、星雲のプロフィール
星雲グラフは、高性能、高可用性、信頼性の高い、一貫性のあるデータ、オープンソースであり、分散地図データベース。
計算された分離を格納する1
ステートフルとステートレスストレージサービスを、星雲設計を使用して計算分離を格納するサービスをコンピューティング、記憶層がデータの信頼性の焦点を改善することができるように、階層的であり、単に界面層を直接計算することができる露光KVが必要なユーザーに焦点を当て計算ロジックにするだけでなく、大幅に運用、保守、展開の柔軟性を向上させます。
しかし、地図データベースとして、性能、柔軟性と性能との間のより現実的なトレードオフである記憶層に図ザ星雲計算ロジックシンクの部分を向上させるためです。
2.強力な一貫性のあるアーキテクチャの主流
星雲いかだの強い一貫性の使用は、主流のアプローチのマルチコピーの一貫で、ユーザーの信頼を高めるために、オープンソースプロジェクトの近くにスタートが便利ですので、これは最初に、適合性試験線形いかだジェプセンによって達成されています。
3.スケーラブル
負荷分散、アーキテクチャおよび実装のための独自のスケジューラ（バランサー）は（今のところあるいは少なくとも）比較的簡単ですしながら、星雲ハッシュベースのマルチいかだにその能力にスケールおかげで、低コストを使用するように、達成されます。
4.簡単メンテナンス
星雲カーネルは、当社の技術開発、インフラストラクチャ・スタックの比較一致で、C ++の実装を使用しています。評価の後、（そのようなインタフェース、展開モデルの監視など）星雲の基本的なプラットフォーム機能を使用するのは簡単です、私たち自身のプラットフォームとの良好なお尻することができます。
優れた抽象コードの実装、複数のストレージエンジンをサポートする柔軟性、以降、私たちのためのシーンのパフォーマンスの最適化機能のために良い基礎を築いを行います。
四、星雲ラフトプロフィール
星雲は、前述した一貫性のある、簡単に概要を星雲いかだの特性を確保強いラフトに依存しています。
主な用語を選択します
Aいかだグループのライフサイクルは、任期が利用できない場合、我々はすぐに次に行くリーダーを開始する任期を選出するそれぞれの事業所の別の用語の後に連続1、フォロワーの他のメンバー、唯一のリーダーの用語、リーダーであります任期、新しいリーダーの選出。このメカニズムは、これまでその守護神下のプロジェクト実施の難易度の筏強いリーダーを作る - パクシ。
2.ログのレプリケーション、圧縮
標準ラフトの実装は、クライアントからの各書き込み要求がWALファイルを書いた「操作ログ」に変換され、リーダーは、日本の運転後に、独自のステートマシンを更新するために、非同期レプリケーションは、すべてのフォロワーをログに記録するためのイニシアチブをとるだろう、フォロワーの応答の半分以上が正常に書き込まれ、クライアントに返されるまで、そうではありませんでした。
合理的なWALログ回復メカニズム、WALファイルがすぐにディスク全体を取り上げるない場合は、実際の操作は、WALファイルが、ますます大きくなり、回復メカニズムは、ログ圧縮（ログ圧縮は）です。ログ圧縮星雲の実装は比較的単純で、ユーザーは一つだけwal_ttlパラメータを必要とし、クラスタの正確さを損なうことなく、ファイルは安定した範囲内のスペースWAL制御を占めることができます。
星雲は、バッチのリーダーにフォロワーをサポートし、効果的に全体のスループットクラスターを向上させることができ、高い同時実行性のシナリオの下で、順不同でログを提出するいかだのバッチおよびパイプラインのメカニズムを達成しました。
3.メンバーの変更
のスナップショットフォーカス機構星雲筏に言及し、典型的ないかだと同様の達成。
グループのメンバーは、筏を増加すると、ノードはリソースのオーバーヘッドである、独自のステートマシン、両方にすべてのログの現在のリーダーから新しいメンバーを取得する必要がリーダーに大きな圧力が得られ、過小評価することはできません。この目的のために一般的ないかだのスナップショットは、このノードの拡張パフォーマンスの問題を解決するためのメカニズムを提供し、適時発行ノードの障害回復ます。
スナップショット、星雲ラフト実装で、別々に格納されている「ミラー画像」とラベルされた、すなわちリーダー自身の状態マシンは、「ミラー」（すなわち、状態機械自体）、新しいメンバーが参加したとき、リーダーがRocksdb呼び出しがイテレータのインスタンス全体をスキャンRocksdbインスタンスであります、卸売区分新しいメンバーの値の読み出し時に、プロセス全体スナップショットの最後の完了のコピー。
4.マルチいかだを実装
クラスタが一つだけ筏のグループを持っている場合、スケールは、非常に限られたアプリケーション・シナリオをマシンを追加することによって達成することは困難である、自然な方法は、異なるラフトグループの複数のデータクラスタは、ここでは2つの新たな問題を紹介し、分割を考えることです。均等に分散クラスタをスライスするための方法をどのようにデータスライス（2）（1）。
マルチいかだは、業界が主流実装の2種類があります挑戦し、非常に興味深いことで達成され、一つはハッシュベース、1地域ベースであり、長所と短所を持っている、ほとんどの場合、前者は比較的単純です効果的な、星雲は、現在、私たちが必要とするものであるハッシュベースのモデルを使用してますが、シーンのマップは、それ以上のフォローアップ計画は存在しない、社会動態は、連続的な注意が必要です。
第五に、導入されたストレージ・プラットフォームの機能
1.システムアーキテクチャ
Redisのプロキシ、Redisclusterプロキシプラットフォームと関連する成分を含む成分の増加した数に基づいて、元のアーキテクチャで星雲、。
メタ情報の例は、それ自体がラフト基でルーティングルールデータ片、空間情報などを含むメタクラスタ全体を、記憶されています。
ストレージノードに格納された実際のデータの例クラスタはラフトグループnに対応する各コピー、Mスライスラフトグループの複数に対応すると仮定される、星雲がmである* nは均等インスタンスストレージの複数に分配コピーとリーダーは、各インスタンスにも似ている番号に努めます。
グラフ描画APIコンソールは、サービスプロバイダだけでなく、クラスタ全体、ステートレスの一例です。
例RedisのRedisの互換プロトコルは、データ構造部は、ネイティブRedisのステートレスを達成します。
Redisのクラスタプロトコル、ステートレスと互換性Rediscluster例。
2.パフォーマンスの最適化
（1）クラスタのチューニング
多くの場合、異なるシナリオのパラメータを調整する必要がアクセス実際の生産事業は、この初期の作品で多くの時間を占めるが、それはまた、私たちのために貴重な経験を蓄積しました。
（2）WiscKey
前述のシナリオのほとんどの機能は、値が頻繁なトリガー圧縮ロジックに深刻な書き込み増幅原因Rocksdbのみに頼る、比較的大きく、それぞれの圧縮は、キーと値が大きな値で、ディスクから一掃することになるだろうシナリオの下で、このオーバーヘッドは非常に恐ろしいです。このため学界は、いくつかの解決策、WiscKey実用性と広く認識を提案し、業界にもそのオープンソース実装（Titandbを）上陸しました。
詳細についてTitandbは彼らを参照して 、公式文書、別々に保存、簡単な言葉で、Rocksdbの変換であり、互換性のある外部インタフェース、予約LSM-ツリー、新しいblobfileを保存、キー値ランダムディスクに依存キー預金LSM-ツリー、バリュー預金blobfileをし、SSD読み取りと書き込みのパフォーマンス、性能を犠牲に範囲クエリは、大きな値のシーンに書き込み増幅を減らします。
星雲星雲ストレージに統合するのは非常に簡単、複数のストレージエンジンの設計、Titandbをサポートするためのおかげで、実際の生産では、本当に私たちのパフォーマンスの良い収入を与えます。
3. TTL機構
かRocksdb、またはTitandbは、圧縮は、特定のデータが除外される必要があるかどうかを決定するために、このフィルタを呼び出すときである互換性の圧縮フィルタ・インターフェースです。私たちは、抽出されたTTLの期限が切れているかどうかを決定するために、それぞれの値、値をスキャンするときに実際に圧縮フィルターで、TTLのストレージに書き込まれた値で成長し、もしそうであれば、対応するキーと値のペアを削除します。
しかし、実際に私たちは価値がblobfileを隔離されている場合は圧縮が重要なの後、フィルター値は（だけ小さい値にLSM-ツリーに滞在することは読み取ることができます）特定を読んでいないときに、Titandbを発見しました。これは、古いデータが得られことは回復する方法はありません、私たちTTL機構に大きな不利益をもたらしました。この目的のために、我々は少し特別な処理をした、大きな価値が隔離されているblobfileを、LSM-木があり、指数の指数値はblobfileを内の位置に、我々はインデックスにTTLの種にしようとしているがDUIキーインデックスに保存されます、作るフィルターすべての物理削除古くなったデータを達成するために、TTLを解決するための時間。
4.使いやすいです
使いやすさが満期データベースのサインです、それは大きな問題です。
異なるユーザの観点から、あらゆる視点でユーザーの役割等、ビジネスR＆Dエンジニア、運用・保守エンジニア、運用、保守、DBAを含むことができ、要件の異なるセットで出てくる、そして最終的に我々は期待を上回ることを願っています真の高使用を達成することができますストレージ製品。ここでは、使いやすさに持っているいくつかの簡単な慣行は、次のとおりです。
（1）互換性のあるプロトコルのRedis
我々は（スタンドアロンのディスクベースのRocksdb KV製品の互換性Redisの契約）は、オープンソースKVrocksの美しさを変換し、ストレージクライアントの星雲C ++バージョンを頼り、Rocksdbの根本的なロジックに依存しては達成するために読み書きするために星雲ストレージKV論理インターフェイスを置き換えますステートレスプロトコルの互換性層（プロキシ）のRedis、我々は実際のニーズに基づいて、いくつかの追加コマンドを実施しました。もちろん、私達はちょうど私最初の秘密の滞在が調整されて、分散トランザクションを検討する必要性に基づいて配布さRedisのKV内の全ての命令と互換性があるように、機能のRedisコマンドのいくつかのシーンを実現しました。
（2）バッチデータKVに導入された支持体からハイブ
シーンは、この機能はまた、使用の容易さを反映して、特徴データの構成を示す現在のデータのための星雲は、ハイブガイド、少し変形缶KV-互換性のあるフォーマットから達成されました。
（3）操作およびメンテナンスプラットフォーム
私たちは公共のクラスタのすべてのメタ情報の中心線上に予め設定され、維持し、そのようなキーの展開クラスタ、アンインストールするクラスタ・キー、定期的なモニタリング報告書として、いくつかの簡単な操作を上陸させた、正確さをチェックするためのコマンドをタイミング、タイミングインスタンスの健康検査、日常の運用および保守の基本的なニーズを満たすために、など、クラスタの負荷監視タイミング。これと同時に、完全に機能するDBaaSプラットフォームを構築する内部インビボでは、実際に最終的な機能、従って、データ管理操作の効率を高める大きく、Redisのは、MySQL、elasticsearch、MongoDBの等を含む、製品のDBプラットフォームの動作および保守の多くをサポートしています使用性と堅牢性の画期的なの使いやすさを実現していき、共進化、ストレージ・プラットフォームは、完全に統合されて追いつきます。
5.災害復旧
（1）定期的なコールドスタンバイ
星雲自体はコールドスタンバイメカニズムを提供し、我々は唯一のパーソナライズされた定期的なバックアップ戦略を設計する必要があり、あなたはここでは詳細に説明されていない素敵なビジネスニーズをより良くすることができ、星雲ので興味の缶を見ている スナップショット機構クラスタ。
（2）リアルタイム追跡
ホットスタンバイは、2つのフェーズの合計を上陸させました。
フェーズ：比較的単純な、増分バックアップのみを考慮し、非可逆を容認。
現在、KV主なサービスは、データ要件の信頼性が特に高いものではなく、場面（シーンやキャッシュ）を備えていて、ストア内の時刻データが存在する長い、TTLはすぐに離れてクリアされますされません。この目的のために、ホットスタンバイの在庫データバックアップスキームをサポートしていません。
「書き込み要求」非同期書き込みに、プロキシ層は、スタンバイクラスタ、クラスタマスターに再びですか限りプロキシCPUリソースが十分であるとして、同期書き込みを実行し続ける増分バックアップ、については、メインクラスタ自体の読み取りと書き込みのパフォーマンスには影響しません。前に述べたようにここでは、そのようなプロキシ非同期としてデータ損失のリスクは、終了しませんでしたがあり、プロセスが突然程度にシーンのほとんどの機能（またはシーンがキャッシュ）、その後、クラスタは1ビットのデータを失うことになる準備、ハングアップが、データ損失が許容されます。
フェーズII：増分バックアップを確実にするために、だけでなく、在庫のバックアップを確実にするために、両方の。
星雲ラフトは、学習者を導入し、それはまた、筏のグループのコピーですが、予備選挙に参加しないどちらも、それだけで静かにログ・コピーのリーダーからの要求を受け、提出過半数には影響しません。他のフォロワー、ハング一度学習者と同じように、リーダーは、再起動回復するまで学習者、学習者へのレプリケーションのログを再試行していきます。
このメカニズムでは、簡単な変更に在庫バックアップを達成するために、我々は、ディザスタリカバリコンポーネントを実装することができ、学習者に変装し、いかだグループにリンクされ、変更機構の後、メンバーは、データと増分のいかだのリーダーの株式ことを保証しますアセンブリ依存星雲ストレージクライアントの他の側面は、クラスタディザスタリカバリへの書き込み要求元のアプリケーションにログデータを変換しながら、ログデータの形で、組立ディザスタリカバリに同期させることができます。
6.クロスダブルリビングルーム
ダブル生活の床は、2つの段階に分けられます。
フェーズI：紛争解決に関係なく、クラスタ間で最終合意することを保証するものではありません。
同じ単純な実現のこのバージョンは、あまり厳しいビジネスや結果整合役立つための都市・アクティブ、フェイルオーバーの要件は、あるため、二つのクラスタ同士の災害と理解されます。
フェーズII：CRDTの導入は、紛争に対処し、最終合意を達成します。
このバージョンでは、信頼性が、2つの複合災害復旧機能を備えた、で学習ログのクラスタ書き込み要求に対するアクセスが比較的高いことが必要です。
通常の状況の関、二つのクラスタは異なる部屋に分散されてもよいKVの下で、各ビジネスサービスのユニットはKV互いに変化に同期二つの異なる部屋、この部屋のKVからデータを読み取ります。2つのKVはキーで更新され、相互に同期している場合、それは、紛争に対処する方法をすべきですか？
絶対的な意味ではなく、書き込み操作の発生のタイムスタンプに応じて、2キーで - 最も簡単な方法は、最終的な合意、「夜」は平均誰もがないことを確認し、2つのKVを更新するために、書き込みデータに最も「後半」です書き込み操作は、それぞれのタイムスタンプに部屋を取ることができますが、実際の動作を引き起こす可能性のあるエンジンルーム、間に必ずしもクロック同期は、第1のタイムスタンプが大きくてもよい発生しますが、私たちの究極の目標は、一貫達成することである、クロックに同期していません機構ライバル関係なので、問題ありません。この考え方では、よく知られたプログラムCRDT結果整合性は、適切な標準の実装を与えられています。
オペアンプベースLWW（最終-書き込み勝利を）達成することであるそのうちの一つの登録データ構造内CRDTに対応するだけでStringデータ型のKV実際の預金、登録は、定義により、最も「後半は」最終的に矛盾しないように値を書いています状態は、アルゴリズムは次のプロトタイプがあります。
オンラインその他の情報でCRDT興味缶一見のため、ここでは詳述しません。
幸いなことに、内部はCRDT登録のRedisのクラスタ上で、生体内で達成されている、と巨人の肩の上に立つことができる新しいKVストレージを作り、全体のデータ保護の信頼性の高い伝送集会室が用意されています。受信した要求における学習者の活性成分がセットに分解リーダー一括書き込みの1を必要とするので、KVラインは、大規模な書き込み要求をMSET、そして唯一の単一の要求の衝突を処理するCRDTレジスタ・セットをサポートしている、という注意コマンド、その後、クラスタピアに同期します。
VIの未来
1.一般的には、店舗のKVに拡張します
私たちは、データベースには、より強力な基盤となって、蓄積時間の特性は、それがKVストレージに共通の目標を作成したプロジェクト。しかし、一般的なKVストアを作るために、それはまた、プラットフォームの能力、を含む、実装する低コストの側面の信頼性を向上させるために多くの作業を必要とします。幸いなことに、業界は良い練習をたくさん持っているし、私たちに大きな基準値を与えます。
2.プラットフォームの機能を改善し続けます
最も簡単な、内部基準生体内だけでなく、大手インターネット企業Redisのプラットフォーム管理の実践、新しいプラットフォーム機能のKVの建設が行うには多くのものがあり、フォローアップのインテリジェントDB運用・保守と結合し、より多くの想像力大規模な。
チェック機構の精度を向上し続けること3。
存在と繁栄のデータの信頼性と正確性がデータベース製品である、我々は適切な検証メカニズムを改善し続ける必要があります。
私たちは、法律、財務データの信頼性レベルにコミットしていないこの段階では、我々は現在のシーンを満たすために、この方向に向けて多数の機能を継続し、シーンのキャッシュが可能です。
私たちは徐々に、より信頼性の高いデータ・ストレージ・サービスをユーザーに提供するために、システムの潜在的な問題を掘るし続けることを期待して、オープンソースツールの混乱の数を導入しています。
4.拡張スケジューリング機能
コアは、可視スケジューリングの重要性を含む3つのトピックをスケジューリングする、コンピューティング、分散データベース・ストレージを中心に構築された、負荷分散を変化させることができ、現在のハッシュベースの断片化ルールの一部である領域ベースのフォローアップスライスのルール？あなたはネイティブの構築にK8S KVクラウドストレージ製品と組み合わせることができますか？データ配信調整賢くを作ることができ、より自動化された......我々は、表示されます。
ホットとコールドデータの分離
自然やコストと性能のトレードオフは、特にいくつかの大規模なクラスタのため、データの90％はほとんどデータがフラッシュメモリに保存した場合でも、訪れないかもしれないが、また、資源の無駄。我々は、データが頻繁にアクセスさせたい一方で、他の一方で、我々はコスト削減を最大化したい、より良い読み取りおよび書き込みのパフォーマンスを得ることができます。
より直接的なアプローチは、データ上の熱とフラッシュメモリを維持することです、風邪データの一部は、システム自体を判断する能力を持っている必要がある、（機械式ディスクなど）いくつかの安価なメディアを凍結保存され、動的に区別するために続けることができます寒データで暑いですデータ、。
ストレージエンジンの6.サポートより多くのタイプ
今RocksdbとTitandbをサポートし、フォローアップは、ストレージなど、純粋なメモリなどのエンジン、またはフラッシュメモリベースのAEPとその他の新ハードウェア製品のストレージエンジンのより多くの種類の導入を検討します。
リモート冷たい7.サポートスタンバイHDFS
オンラインシナリオでは、データのバックアップは非常に重要であり、現在のスナップショットバックアップ星雲は、ローカルクラスタレベルをサポートしてきましたが、マシンがハングアップ、または大量のデータ損失のリスクがあり、我々は、HDFSとして、遠隔冷たいスタンバイにデータを検討します。HDFSは限りコストがそれを指定したディレクトリに移動し、クラスタのスナップショットダンプをすることができますマウントするようではないでしょうか？私たちは、さらに思考とデザインを行います。
8. SPDKディスクの読み取りと書き込み
実際の試験を教えてくれる、それがSPDKがほぼ倍増しない場合よりもスループット向上させるスタンドアロンSPDKを使用し、またのNVMeディスクに依存しています。カーネルSPDK BYPASSこのプログラムは、一般的な傾向となっている、ディスクIOは簡単SPDKが効果的にリソースの使用率を向上させることができます使用して、ボトルネックのシナリオになります。
9. KVのSSDは
与えられたSPDKバイパスカーネルの利点は、業界では、新しいソリューション（KV SSD）を提案しました。
Rocksdb LSM-ツリーリアライズ、圧縮メカニズムは、深刻な書き込み増幅の原因となりますし、KV SSDは、新しいデータレコードに基づいてネイティブKVインタフェース、互換性のあるRocksdbのAPIを提供してSSDに直接書き込むことができ、あなたは繰り返す必要はありません圧縮操作は、新しい技術を書き、それによって拡大Rocksdbに減少、それはしようとして非常に価値があります。
図10におけるサポートデータベース。
当社の製品は、KV星雲を命じてきた、一つの重要な理由は、オープンソースコミュニティが協力し、主要な地図データベースの機能を構築できるようにしたかった後、我々は、ビジネスのいくつかの作図のニーズにアクセスしようとしている地図データベースの準備をすることです。
11.タイミング・データベースのサポート
5Gは、物事の時代に、タイミングデータベースは、非常に重要な役割を果たしています。
主要このフィールドInfluxdb電流が、オープンソースバージョンは、それが単一の系列のデータ・ストレージ・エンジンの設計（TSM）、非常に限定されるもので実用的な価値のための1つに依存する、分散をサポートしていません。
当社の製品はすぐKV分散レプリケーション機能、標準化プラットフォーム機能、高可用性、セキュリティ対策を提供し、我々は可能な限り再利用することができるように願っています。
コンバイン可用性の高い分散ストレージエンジンのタイミングを構築し、分散レプリケーションの統合を行う能力、プラスシャーディング戦略タイミングフレンドリーシーンでTSMを考慮することはできませんが、オープンソースInfluxDBのスタンドアロンのストレージ層を交換してください。
12. A支持オブジェクトを格納するメタデータ格納
メタデータは、それを維持するための負担を軽減するために、それがアップして再利用することができ、運用、保守、および研究開発されていない「オブジェクトストレージ」保管するために重要である、我々は強力なKVストレージ製品を提供しておりますので、ですか？
最終的に七、
私たちは、下の自分の感情や経験を述べ、リソース、要件収集、反復製品の連携のプロセスを実践し続け、およびアクセスに努力し、よりシーン、収集より多くの需要を、より良い私たちの製品を磨き、できるだけ早く好循環を入力する必要があります。
もっとお楽しみに インターネット技術VIVO マイクロチャネル公共番号
注：マイクロ・シグナルとの記事を転載してください：labs2020 連絡を。