postgreSQL vs Cassandra vs MongoDB vs Voldemort？
どのデータベースを決定しますか？比較はありますか？
- 既存：postgresql
- 問題
- 水平方向に簡単に拡張することはできません。シャーディングなどが必要
- クラスタリングはデータ増加の問題を解決しません
- 探しているもの：水平方向に簡単にスケーラブルなデータベース
- Cassandra（Twitterはそれを使用していますか？）
- MongoDB（急速に人気を博している）
- ヴォルデモート
- その他？
- なぜ？
- 雪玉効果でデータが増える
- 定期的にvaccuumタスク用の既存のpostgresqlロックテーブルなど
- 現在、データのアーカイブは膨大です
- 既存のアーカイブ、バキューム、...に定期的に関与する人間の相互作用
- 'が必要です。忘れてください。データがさらに大きくなったときに、別のサーバーを追加するだけです。」ソリューションの種類
最初の質問：ACIDプロパティが必要ないのに、なぜ最初からリレーショナルデータベースを使用しているのですか？ある種の非トランザクション作業を行っているように思われるため、トランザクションを含むRDMBSを取得することは、おそらく環境にとって重すぎます。
2番目の質問：どのような種類のデータを保存していますか？列ストアデータベースが必要であり、それはある種のデータウェアハウスプロジェクトに適しているようです。
3番目の質問：PostgreSQL（そのままのデータベースです）に悩まされている場合、それが現在のバージョンですか？古いバージョンの8.xより前のバージョンは遅いことで有名ですが、それ以来、作業の多くが改善されており、オートバキュームなどの問題のいくつかは、「set-and」で簡単に対処できるようになりました。 -設定を忘れる。
* Data growing with Snowball effect
これに関するいくつかの追加情報はいいでしょう。なぜ雪だるま式になっているのですか？ストレージを減らすために正規化できますか？
* existing postgresql locks table etc for vaccuum tasks periodically
これが問題である場合は、古いバージョンを実行していることがすでにわかります。新しいバージョンには、これに対するテーブルごとのコントロールがあり、完全にオフにすることもできます。
* Archiving data is tideous currently
扱うことがあまりないので、ここでどんな種類の判断もするのは難しいです。ダンプされるアーカイブはどのメディアですか？どのくらいの持続的なI/Oが関係していますか？どのような時間枠で運営していますか？データ量は？ 「ホット」ダンプである必要がありますか、それとも「コールド」である必要がありますか？
* Human interaction involved in existing archive, vaccuum, ... process periodically
「通常の」使用には手動の介入が必要ではないので、どのように必要になるかを確認しようとしています。バキュームは現在自動であり、（前述のように）まったく発生しないように設定でき、ほとんどのバックアップはスクリプト化されます（スクリプト化できる場合は、スケジュールできます）。それで、これはどのように起こっていますか？
* Need a 'set it. forget it. just add another server when data grows more.' type of solution
あなたはクラスター化されたサーバーの配置について話している。
私には次のように聞こえます：
- あなたはRDBMSを使用しており、そのトランザクションの性質はアプリケーションに適していません。
- アプリケーションは、ほとんどが読み取られるスタイルのデータベースを必要としているようです。また、トランザクションの整合性を保つために必要なようにも思えません。
- 処理しているデータの量は、ほとんどの場合正規化されておらず、正規化の試みも行われていません。
- 手作業でやりすぎて、もっと自動化が必要です。
- クラスター化されたソリューション、おそらく「クラウドスタイル」のコンピューティングのアイデアが好きです。
それ以外に、適切なものが何であるかを理解するのに十分な情報がここにはありません。
HBaseとHyperTableも検討することを検討してください。ただし、繰り返しになりますが、Avery Payneが述べたように、現在のアプリケーションに関する情報は提供せず、データベースプラットフォームのみを提供します。
覚えておくべきいくつかのこと：
結合は、SQL以外のプラットフォームでは手動で行われます。外部キーや集計などは実行されません。これらはすべて手動です。
既存のアプリケーションの移植は必ずしも簡単ではありません。移植にかかる費用によっては、PostgreSQLサーバーを（水平方向ではなく）垂直方向にスケーリングする方が費用対効果が高い場合があります。
ACIDを取得せず、並行性を手動で管理する必要があります。アプリケーションによっては、これが問題になる場合があります。また、原子性の欠如のために、従来の方法でグローバル保護ルールを適用することもできません。
Cassandraは、スケーリングが必要であることがわかっている場合に最適なオプションです。
http://wiki.Apache.org/cassandra/ArticlesAndPresentations のケーススタディ記事のいくつかをお勧めします
一部の問題を解決するためにできることは次のとおりです。
- 定期的にバキュームタスク用の既存のpostgresqlロックテーブルなど
テーブルはロックされていません。パフォーマンスが遅いだけです。これは、トランザクションIDの折り返しを防ぐためにpostgresqlによって行われます。複数の行をバッチで書き込んでからコミットすることで、頻度を減らすことができます。中間書き込みには（rabbitmqのような）キューを使用できます：application-> queue-> db。これにより、書き込みパフォーマンスも大幅に向上します。
- 現在、データのアーカイブは膨大です
データが数桁で大きすぎる場合TBダンプはオプションではないため、クラウドに移行することをお勧めします。AWSまたはGoogle Cloudを使用し、スナップショットを使用します。例：EBS非常に高速なスナップショットは、大陸間で複製され、バックアップの必要性を解決します。
アーカイブとは、データを削除して「アーカイブ」に移動することを意味する場合は、日付でローテーションされるテーブルスペースを使用します。これにはオンラインでいくつかの実装があります。