次の新しい光沢のあるもののためのデータストアを選択する方法

注：これは、プリンシパルエンジニアのSilvia Botrosによって書かれた技術的なブログ投稿であり、2017年12月25日にSysadventブログに最初に掲載されました。

データベースは難しい場合があります。 何が難しいか知っていますか？ そもそも1つ選ぶ。 これは、製品/市場の適合性をまだ見つけている新しい会社にいる場合でも、オーディエンスを見つけて単に製品の提供を拡大している会社にいる場合でも、困難です。

新しいものを構築するとき、その設計プロセスの最初の部分の1つは、どのデータストアを使用する必要があるか、そしてそれは単一または複数である必要があるかということです。 リレーショナルストアを使用する必要がありますか、それともキーバリューストアを選択する必要がありますか？時間オプションはどうですか？ 分散ログの再生にも振りかける必要がありますか？

それで。 たくさんの。 オプション…

この記事では、その決定をうまく導くプロセスについて説明し、該当する場合は、組織の規模と成熟度がこの決定にどのように影響するかを説明します。

ベースライン要件

データはあらゆる製品の生命線です。 アプリケーションの状態を保存するためにより多くの最先端テクノロジーを使用するように設計を計画している場合でも（MySQLまたはPostgresはもはや「クール」ではないため）、選択するものはすべてデータストアであるため、次の場合に厳密に適用する必要があります。私たちの選択をします。

覚えておくべき重要なことは、無料のものは何もないということです。 すべてのデータストアには妥協点があり、ビジネスリスクとしてどのような妥協点をとっているのかを明確にしないと、最悪の場合に現れる未知のリスクを冒すことになります。

プロダクトマネージャーは、データストアに何を使用しているかを知る必要はなく、気にする必要もありませんが、オプションリストを縮小するニーズを推進します。 ただし、それでも開発チームによる調整が必要な場合があります。 オプションの推進を支援するために製品チームに依頼する必要があるもののリストは次のとおりです。

• 成長率：データ自体またはデータへのアクセスは、時間の経過とともにどのように変化すると予想されますか？
• 請求チームはこの新しいデータをどのように使用しますか？
• ETLチームはこのデータをどのように使用しますか？
• この新機能にはどのような精度/一貫性の要件が期待されますか？
• その一貫性のためにどのくらいの期間が許容されますか？ 後処理の修正は受け入れられますか？

言われていない文脈を見つける

データストアの選択は、DBAやOpsチーム、あるいはコードを作成するエンジニアのために予約された選択ではありません。

既知のアドレス可能な市場を持つ成熟した組織は、組織全体の利害関係者から決定を下す必要があります。

製品チームからの要件が12のデータストアに適合する場合、明示的に呼び出されていない要件をどのように判断しますか？

それは将来の失敗した期待への道であるため、あなたはできるだけ早く暗黙の要件を明らかにする必要があります。

多くの暗黙の事柄は、この「選択肢が多すぎる」トラップで失敗する可能性があります。 これには以下が含まれますが、これらに限定されません。

• 不完全な機能リスト
• 明示的にリストされていないパフォーマンス要件
• 想定される一貫性のニーズ
• 指定されていない成長率
• まだ利用できない/不明な請求またはETLクエリのニーズ

これらはすべて、エンジニアリングチームが作業している明示的な基準が許容範囲を超えているか不完全であるという理由だけで、データストアの選択肢の長いリストを審査するのに時間がかかりすぎる可能性があります。

前に述べたように、より多くの「グリーンフィールド」製品の場合、目標は柔軟性です。 したがって、より汎用的で既知の品質のデータストアは、成果物に近づくのに役立ちます。将来的には、新しい規模に適したデータストアに移動する必要があるかもしれません。

リストを作成する

要件のリストで潜在的なソリューションをフィルタリングするときが来ました。 結果のリストは、可能なデータストアのほんの一握りである必要があります。 使用できる可能性のあるデータベースのリストがそれ以上の場合は、要件が許容範囲を超えているため、戻って詳細を確認する必要があります。

若くて成熟度の低い企業にとって、データストアの要件は最も未知数の領域です。 あなたはおそらくまだ誰も提供していない新しいものを構築しているので、アドレス可能な市場の合計サイズや成長率などは比較的不明であり、定量化するのが難しいかもしれません。

この場合、必要なのは、ワントリックポニーデータストアを使用して、新しい会社の存続期間の早い段階で自分自身を制約しないことです。 はい、ある時点でデータは新しい予期しない方法で成長しますが、今必要なのは、市場のニッチを見つけてデータの成長がどのように見えるか、特定のスケーラビリティ機能が重要になることを学ぶときの柔軟性です。あなたの成長。

有料の顧客が増えている大企業の場合、ここでのタスクは、オプションリストを、できれば既存のデータストアに縮小して維持することです。 すでに多くの有料顧客がいる場合、チームが精通していない新しいデータストアを追加するリスクは高くなり、データのコンテキストによっては、単に受け入れられません。

もう1つ覚えておくべきことは、データストア用のツールがすでに存在することと、新しいツールを採用することは、チームが行う必要のある事前の作業に関して何を意味するかということです。 構成管理、バックアップスクリプト、データリカバリスクリプト、新しい監視チェック、構築して理解するための新しいダッシュボード。 リスクに関係なく、新しいデータストアの運用コストのリストは簡単ではありません。

あなたの毒を選んでください

したがって、DBAが保持しているひどく守られた秘密がここにあります。 データベースはすべて何かでひどいです。 それについては完全な定理さえあります。 従来の意味でのデータベースだけでなく、状態を保存する技術は、それを使用する方法に固有の方法で恐ろしいものになります。

それはあなたが今よりよく内面化する人生の事実です。 いいえ、私はあなたがこれらのテクノロジーの使用を避けるべきだと言っているのではありません。あなたの期待を正気に保ち、あなたとあなたとあなたのチームだけが最終的にあなたの約束を果たすことを所有していることを知っていると言っています。

これは非抽象的にはどういう意味ですか？ どのデータストアが構築するものの一部になるかをしっかりと理解したら、これらのデータストアの弱点を知ることから始める必要があります。 これらの弱点には、次のものが含まれますが、これらに限定されません。

• このデータストアはスキャンクエリでうまく機能しますか？
• このデータストアは、データ複製のためにゴシッププロトコルに依存していますか？ もしそうなら、それはどのようにネットワークパーティションを処理しますか？ そのゴシップにはどのくらいのデータが含まれていますか？
• このデータストアには単一障害点がありますか？
• コミュニティのドライバーは、コミュニティと話をするのにどれくらい成熟していますか、それとも自分でロールする必要がありますか？
• このリストは膨大になる可能性があります

あなたのリストにまだある潜在的な解決策の弱点を考えることは、リストからより多くのオプションをノックアウトするはずです。 これは今や、テクノロジーの高い約束を実現する現実です。

スプレッドシートと焼き払い！

選択肢のリストがほんの一握りになったら、それらすべてをスプレッドシートに入れて、もう少し深く掘り下げ始めましょう。 長所の列と短所の列が​​必要です。この時点で、特定のタスクを実行する方法の詳細を確認するために、各データベースのドキュメントに時間を費やす必要があります。

これが大きな成長率を期待するデータである場合、これらのオプションのどれがスケールアウトしやすいかを知る必要があります。 これが多くのあいまい検索を行う機能である場合は、どのデータストアがスキャンを処理できるか、または多数の行をどのような設計でより適切に検索できるかを知る必要があります。 この段階での目標は、ドキュメントだけでリストを2つまたは3つのオプションに絞り込むことです。これは、この新機能が会社の成功にとって十分に重要である場合、3つすべてのベンチマークを行う必要があるためです。

なぜベンチマークと言うのですか？ 同じデータストアを同じように使用している企業は2社もないからです。 時々、ドキュメンテーションは他の人の戦争物語でのみ明らかにされる警告を暗示しているからです。

このデータストアの安定性、信頼性、予測可能性を所有しているのはあなただけです。

事前にベンチマークを設計します。 理想的には、リスト内のデータストアの完全なインスタンスを本番レベルの仕様でセットアップし、負荷テストを役に立たなくするほど小さすぎないテストデータを作成します。 「通常の負荷」のベンチマークだけでなく、いくつかの障害シナリオをテストすることも忘れないでください。

ベンチマークを通じて、すべてのコードが記述され、多くの時間でファイアドリルフェーズにいるときに、後でではなく、今すぐオプションリストに再度アクセスするのに十分な重大な警告を見つけることができることを願っています。そしてあなたがした選択にコミットした努力。

選択内容を文書化する

あなたが何をするにしても、あなたはあなたがあなたの選択に到達した方法とその決定へのルートで調査された代替案を内部で文書化して放送しなければなりません。 この新機能とそのすべてのコンポーネントがどのように作成されるかについての包括的なアーキテクチャの青写真があると仮定して、チームが下した決定に到達するために行われたすべてのベンチマークへのリンクを備えた、この新機能を強化するデータストア専用のセクションを作成してください。 。

これは、将来の新入社員の利益のためだけでなく、現在のチームの利益のためでもあります。 人々が非同期的に読んで意見を発展させることができるドキュメントは、意思決定プロセスを透明に保ち、チームメンバーの間で最善の意図を育み、予測していなかった視点から批判をもたらす方法を提供します。

要点

これらのステップは、ビジネスオファリングを成長させるときにデータに基づいた意思決定につながるだけでなく、堅牢なインフラストラクチャと、成長し続けるテクノロジーの分野をいつどこで使用して支払いに価値を提供するかについてのより統制のとれたアプローチにもつながります。顧客。