どのデータベースを選択するかの推論

この記事は、次の場合に役立ちます。

• 新しいプロジェクトのデータベースを選択し、さまざまなオプションに関する情報を学習します。
• 現在のデータベースは一部のパラメーターに適していないと考え、それを変更したいのですが、優秀な専門家がいません。
• いくつかのデータベースについて、そしてそれらをいつ使用できるかについて、1つの記事で読みたいだけです。

私の記事はあなたのためではありません：

• お気に入りのデータベースをクックする方法、インデックスを最適化する方法、調整する方法などを知っている。
• プロジェクトに必要なオプションを合理的に選択できるスタッフの優れたスペシャリストがいます。 専門家は、「ソファの専門家」ではなく、本当に優秀でなければなりません。
• いわゆる「ビッグデータ」を使用してプロジェクトにサービスを提供しています。つまり、巨大なデータベース、クラスター内に数十または数百のサーバーがあり、すべてがそうです。

この記事では何が議論されますか？

私の記事では、データベースを選択するための典型的であまりオプションではないいくつかのオプションについて説明します。 ほとんどの人が使用するものに焦点を合わせるとき、そしてあなたが何か新しいことや未知のものについて考えることができるとき。 DBMS MySQL、PostgreSQL、MongoDB、Redis、CouchDB / PouchDBを説明し、Tarantoolを使用したAerospikeをいくつか紹介しますが、特定の選択はそれほど重要ではありません。 DBMSを選択するよりも、最初にデータ構造を正しく設計する方がよいことを理解する必要があります。その後、DBMSに格納するものを考え出そうとします。

それでは始めましょう。

小さな偏差：

1. 私の計算は究極の真実ではありません。 実際の使用に基づいていくつかの結論を出し、インターネット上の情報に基づいていくつかの結論を出し、他の人々と議論しました。 いくつかの結論は実際の問題に基づいており、いくつかは純粋に理論的なアイデアに基づいています。 この情報はすべてインターネット上で何らかの形で存在しますが、かなり散在していますが、1か所で簡潔に説明しようと思います。
2. 執筆時点で積極的に開発されていると同時に、長期間安定して存在する製品のみを検討します。 繰り返しますが、私の意見では、プロジェクトに何かを選択するための条件の1つは、製品が十分に安定し、動作し、大きくてよく発達したコミュニティを持つこと、その使用はタンバリンとの複数日間のダンスなどに関連しないことです そして重要なこと-商用サポートを公式に使用し、それによって開発者から保証を取得する機会があるはずです。 他の多くのオプションがあることを心に留めておく必要がありますが、それらは未加工であり、プロジェクトにそれらを伴うには、追加の不合理な努力をする必要があります。 あまり成功していないか人気があります。
3. コメントであなたの意見を読んでうれしいです。 そして、記述されたデータベースについてだけでなく。 そして、私だけでなく、多くの人がデータベースについての合理的な意見を読むことに興味があると思います。
4. 最も重要なことは繰り返しますが、ここでは大規模なプロジェクトについては説明しません。 このようなプロジェクトには、通常、すでに独自のアーキテクトまたは知識のある人と、最良の選択を提供するのに十分な資金があります。 誰が知っているかもしれませんが、私の計算とそれらは役に立つでしょう。

では、自分で質問しましょう。

• あなたはどれほど保守的ですか、あなたは新しいものを掘り下げたいですか？
• 考えたくない、またはその逆は、データベースデバイスを徹底的に掘り下げたいですか？
• あなたのチームのプログラマーはどれだけ優れていますか？データベース構造を有能に構成することができますか？それとも、あるDBMSの優秀なスペシャリストですか？

答えましたか？ そう？ 次に、DBMSをリストし、その場合に注意することをお勧めします。



MySQL / MariaDB



人気のあるDBMSまたは「必須」は、ほとんどすべてのホスティングにあります。 簡単にインストールでき、特別な設定なしで正常に動作します。 適切なアプローチにより、ニーズに合わせて柔軟にカスタマイズできます。 ただし、落とし穴があります。場合によっては、DBMSとデータ構造をどのように調整しても、非常に狭いネックになり、プロジェクトの速度が低下します。

MySQLは次の場合に最適です。



-あなたは保守的で、DBMSの設定を掘り下げたくなく、インストールして動作しているだけです（まあ、またはホスティングで、与えられたものを使用してください）。

-あなたは保守派なので、構造的に、表形式で考えます。 MySQLが処理します。

-任意のプログラミング言語、フレームワーク、CMS、CMFなど-MySQLとの統合があります。

-新規であり、構造データを管理するDBMSが必要です（できれば1〜2ギガバイトまで）。



短所？ それらがあり、重要なDBMSがあれば、別のDBMSを選択する必要があります。



-平凡なパフォーマンス。 本当に低い、チューニングしないでください。 クラスターでさえあまり役に立ちません（設定する必要があります。そう、それらはまだタンバリンで踊っています）。 20 MB /秒のオーダーの数値について話しています。 個人的な経験から、MySQLはそのようなフローを備えたSSDディスク上で、対応できず、速度が低下し、さらにサービスは数年間調整され、負荷に最適な設定が使用されました。 箱から出してすぐに設定できるので、必要なバーはさらに少なくなると思います。

-データ構造の変更は、特に異なるテーブルのデータ間に多数の関係がある場合や、フィールドを単純に追加する場合でも、かなり時間がかかるプロセスです。

-サーバーの不安定性に対する感度。 これは、PerconaのXtraDBを使用する場合に特に当てはまります。 MySQLが正常に終了しない場合、テーブルとデータベースが破損する可能性があるため、もちろん定期的に行うと完全バックアップからのみ復元できます。 そして私を信じて、これは常に最も予想外の瞬間に起こります。 単純な状況ではパフォーマンスを回復するのに役立つツールがありますが、万能薬ではありません。 最新および現在のバージョンでは、彼らはこれに積極的に取り組んでおり、はるかに優れた安定性と信頼性が宣言されています。



PostgreSQL



一種のマストドン、非常に古くて有能なDBMS。 それはほとんどMySQLに似ていますが、より優れています。 ただし、料理とセ​​ットアップができる必要があります。 多くの非常に安定したDBMSによると、MySQLのようにテーブルを削除、破壊することはほとんど不可能です。 そして、これは選択する際の決定的な要因かもしれません。



PostgreSQLは次の場合に最適です。



-あなたは保守的であり（繰り返しますが、そうです）、信頼できるストレージが必要です。

-あなたまたはあなたの専門家がPostgreSQLを設定および使用できます。

-適切に構造化されたデータが必要ですが、データスキーム（JSON / BJSON）にはある程度の柔軟性があります。

-サードパーティのライブラリを使用すると、クラスターに拡張し、テーブルを分割するのが簡単で便利です。 そして、それはすべて本当に機能します。



しかし、それは実際にマイナスを記述する方法ではありません...公平に、私はあまり練習を持っていませんでした、私は主に友人の話から判断します：



-このDBMSを適切に準備するための経験が必要です。 それ以外の場合は、MySQLを使用するか読み進めることをお勧めします。

-デフォルトの認可システムは、使用または設定時に困難を引き起こす可能性があり、誰もがそれを好むわけではありません。



モンゴッド



ああ、まだ壊れているコピーの数-SQLまたはNoSQL ...しかし、場合によっては、MongoDBはMySQLやPostgreSQLよりもはるかにうまく対処できます。 たとえば、私が目撃した実際のケース-ホスティングに関する統計の収集と処理（CPU、I / O、メモリなどの負荷）-MySQLはその言葉にまったく対処できませんでした。 MongoDBはあまり問題なく処理しました。 データベースの容量は200〜300 GBに達し、データストリームは100 MB / s以上に達します。 有意義に、私の意見では。



MongoDBは次の場合に最適です。



-事前に定義された明確なデータ構造を持っていないか、データ構造が劇的に変更できると仮定します（もちろん、これはSQLで実行できますが、他の用語で考える必要があり、変更できますが、問題はどれだけ時間がかかるかです）;

-かなり深刻なデータ（数十または数百GB）を計画している場合、TKの段階でもこれを判断できます。

-NoSQLが必要なだけで、ファッショナブルです。

-インストールと試用が簡単で、特別な設定なしで正常に動作します。 そして、さらに深く勉強すれば、たくさんの設定ができます。



短所も。



-単純なトランザクションはありません。 MySQL / PostgreSQLのように、少なくとも古典的な形式では。 相互に依存する大量のデータを追加する場合、コードレベルで個別に解決する必要がある特定の問題が発生する可能性があります。 まあ、つまり、あなたはもちろん出くわさないかもしれませんが、...;

-データ接続は実質的にありません。 すぐに思い浮かぶ、SQLからのJOINが絶えず言及されています-これは本質的にはありません。 より正確には、他のカテゴリで考える必要があります。

-NoSQL専用の思考を再構築する必要があります。 そうしないと、保守が困難になります。つまり、将来、優れたプログラマー（より正確にはソフトウェアアーキテクト）が必要になります。



レディス



ほとんどの場合、このDBMSは、より低速な別のDBMSからのデータを操作するためのキャッシングレイヤーとして使用されます。 それが何かを教えてくれるなら、最高のmemcachedの置き換え。 まれですが、データのスタンドアロンデータベースとして使用できます。 同時に、Redisはリスト、キュー、Pub / Subを含むさまざまなタイプのデータを実行でき、TTL（キーの有効期間）を使用するのは非常に簡単です。 メモリ内で動作し、非常に高速で、データをディスクに保存する方法を知っており、上書きのサポート（ディスクへの負荷がはるかに少ない）と起動時にロードします。 ほぼおとぎ話。



Redisは次の場合に最適です。



-データ量が小さく、テンプレート「key = value」に収まる非常にシンプルなスキーム。

-マスターの簡単な実装-スレーブ複製。 本当に非常に簡単なセットアップです。サーバー構成にウィザードを追加し、Redis Serverを起動するだけで、データは既に複製されています。 おそらく、柔軟なレプリケーション（部分）を構成する可能性は低いことを明確にする必要があります。

-Pub / Sub（キュー）が必要です。 公平を期すために、このパターンに加えて、他のものを実装する別個のPub / Subシステムがあると言わなければなりません。 Redisはこれを非常にエレガントかつ簡単に実装します。他の人は必要ないでしょう。

-遅いDBMSのキャッシュが必要な場合、またはそのボリュームに注目してDBMSの速度を考えたくない場合。 例は、MySQLにメインデータベース、RedisにキャッシュがあるDrupalのサイトです。 通常のabに興味を持たせるためにテストを実施すると、コンテンツ配信の速度が大幅に向上します。 通常のApache + Redis + mod_phpでは、Nginx + php-fpmと同等のパフォーマンスを実現できます。また、ReginをNginxに追加すると...



欠点もあります。



-データの量は、サーバー上の空きRAMの量を超えてはなりません（実際には使用できますが、その後、すべてのスワップがスワップになり、大幅にスローダウンします。一般的には避けるべきです）。

-パフォーマンスのために、データの安全性はかなり弱いです。 つまり、データが追加されることはよくありますが、再起動後は追加されません。 AOL（ファイルの追加）を有効にすると、状況は少しスムーズになりますが、ディスクからのロードは非常に長くなります。

-トランザクションと関連データは可能なものではありません。 より正確には、PipelineとMulti / Execがありますが、これはまだ古典的な意味でのトランザクションではありません。

-クラスター化とシャーディングを通常どおり行う方法がまだわかりません。 通常の実装はまだありません。



もちろん、特別なスクリプトを使用して、クラスターに似た何かに負担をかけたり実行したりできますが、私の意見では、かなり曲がっており、最適ではないように見えます。

代替案

個人的な経験やインターネットの閲覧、さまざまな記事、レビューの勉強から、以前のオプションに慣れていない場合に適用できるいくつかの異なるオプションに出会いました。 それで、もっと面白いプロジェクトに会ってください。



IBM Lotus Domino / Notes



私の意見では、成功した商業プロジェクトの最も明確な例は、NoSQLコンセプトのDBMSです。 成功はおそらくNoSQLではなく、組み込みのコードエディターとデータベースへのインターフェイスを備えた本格的なアプリケーションサーバーの存在下であると思われますが。 このソリューションは非常に成熟しており、長い間市場に存在し、巨大なIBMによってサポートされています。つまり、非常にクールです。 彼は個人的に、それに基づいた2つの異なる電子文書管理システムの開発に参加し、銀行の重要なアプリケーションにも同行しました。 ちなみに、有料配布ポリシーにもかかわらず、知っている人はほとんどいませんが、無料でダウンロードして学習できます。



Couchdb



さまざまな構造のドキュメント（たとえば、MongoDBなど）を保存しますが、アプリケーション用のアダプターがないか、余分な依存関係が必要ないのですか？ CouchDBはhttpを介して動作し、組み込みのWebサーバーを持ち、JSONで交換します。 とても快適です。 ところで、彼はトランザクションの方法を知っており、データの変更をサブスクライブできます。 しかし、これは正確ではありません。



ポーチドブ



これは、CouchDBに類似した非常に興味深いプロジェクトですが、より日常的な組み込みオプションです。 アプリケーションに組み込まれ、ローカルデータベースとして動作しますが、CouchDBまたはPouchDBサーバー（ExpressJSに基づく）でレプリケーションをカスタマイズできます。 PouchDBは実際にはCouchDBに似た単一のAPIを使用して外部から作業するレイヤーですが、内部にはSQLiteとLevelDBの両方、ブラウザーデータベース、MongoDB、さらにはMySQLなど、まったく異なるDBMSがあります。 データ交換が重要であるが、サーバーとの通信が不安定または一時的な分散アプリケーションを作成している場合に非常に役立ちます。



エアロスパイク



私の意見では、キー/値データベースに関してはRedisの優れた代替品です。 トランザクションが可能で、データを保存でき、大量のデータ（使用可能なRAMの量を超える）が可能です。 確かに、Pub / Subおよび特別なデータ構造はありませんが、迅速かつ適切に機能します。 おそらく唯一の欠点は、Redisに比べて人気が低いことです。 理由は明らかではありません...



アパッチカサンドラ



ビッグデータ用の分散NoSQL DBMSとして設計および機能します。 データは一連の列の形式で保存され、最初はアプリケーション開発のアプローチを劇的に変えることができます。 しかし、あなたの心を壊した後、これがまさにあなたが必要とするものであることが判明するかもしれません。 ノードのオンザフライでの単純な追加、ノードの1つが終了したときの高いフォールトトレランスを宣言しました。 理論的には、小さなプロジェクトで使用できますが、おそらく顕微鏡で釘を打つように見えます。



タランツール



Mail.Ruの素晴らしいプロジェクト。 Redis / AerospikeとMongoDBの間の何か...私の意見では、開発者自身はまだ類推するのが難しいと思っていますが:)。 あなたは料理をすることができ、より正確にしたい必要があります。 そして、それはチューニングに関するものではなく、Tarantoolの新しいバージョンの開発への絶え間ない適合性に関するものです。 このプロジェクトの内部構造を掘り下げ、そのAPIとドキュメントの変更を常に調査し、常に変更のためにアプリケーションコードをカスタマイズする必要があります。 また、開発プロセスにも参加したい場合は、開発者とチャットしてください。



そして今、それがすべてだったのです。



はい、すべてのDBMSから遠く離れた場所に言及しました（ このサイトを見ると、253の名前がリストされています）。 私はそれらをすべてリストするだろうと思わなかったと思いますか？



おそらく、1つまたは別のDBMSの説明で間違いを犯し、重要なことについては言及していません。 これは非常に可能であり、もしそうなら-コメントを書いて、私は興味を持って読みます。

私の結論が有益で興味深いものになることを願っています。



UPD1 ：MySQLフェイルオーバーについて。 あなたは大丈夫です。 InnoDBが不安定であることは宣言しませんが、状況が発生する可能性があると述べました。 そして、それが発生した場合、作業容量を復元することはできず、バックアップからすべてを完全に復元することしかできません。 これはまさにこれが何についてなのかであり、あなたが私がそれを不安定だと考えると決めたわけではありません。 実際の例によると、サーバー上では、昨年に2〜3回これが発生しました。 異なるサーバー上。 サーバーには、異なる負荷、ボリュームなどを備えた数百のデータベースがあります。 これは、1つまたは2つのサイトを持つ仮想マシンでMySQLが定期的にクラッシュするという意味ではありません。これはまったく問題ではありません。 このようなもの。