27

データベース サーバーに完全なデータベースをキャッシュするのに十分な RAM を搭載するのが一般的になっていると思いました。数年前に大流行したメモリ データベースのスペシャリスト ( TimesTenなど、ウィキペディアのページも参照) が使用されていないのはなぜですか。もっと？

時が経つにつれて、ディスクベースのデータベースの使用が減少しているように見えます。たとえば、ほとんどのアプリケーションは現在、従来の合理的なデータベース上に構築されています。多くのサーバーで RAM が空きに近づいているため、逆の結果になると予想していました。

stack-overflow-architecture を読んだところ、ページに次のように書かれているので、これを尋ねています

Stack Overflow のデータベースはほぼ完全に RAM 内にあり、結合の正確なコストは依然として高すぎるため、これは重要です。

しかし、通常の btree の代わりに「ポインタ」と「コレクション」が使用されていれば、これは問題にならないと思います。Btree は、ディスク アクセス速度の制限を回避するのに非常に巧妙です。たとえば、ディスク使用量を減らすために CPU 使用率を交換します。しかし、今ではマッチラムがあります。

ただし、独自に行うように、データベースはまだ必要です

  • ロック
  • デッドロック検出
  • トランザクション ログ
  • 回復
  • 等

非常に難しいです。

@S.Lott、インデックスの選択、結合の回避、データベースのパフォーマンスの問題の調査に非常に長い時間を費やしていることを考えると。もっと良い方法があるはずです。数年前、「メモリ内データベース」の方が優れていると言われました。だから、私がそのようなものを使う前に、なぜ他の人がそれらをもっと使わないのか知りたい.

(TimesTen は価格が高く ( $41,500.00/Processor )、Oracle の営業担当者と話すのは好きではないので、自分で TimesTen を使用することはほとんどありません。コードを書くことに時間を費やしています。)

以下も参照してください。

アップデート：

私はずっと前にこの質問をしました。最近の Microsoft SQL Serverには、SQL Server エンジンに統合されたメモリ最適化データベース エンジンである「インメモリ OLTP 」があります。安くはありませんが、一部のワークロードでは非常に高速なようです。

4

9 に答える 9

13

「インメモリデータベースの使用をいつ検討する必要があり、注意すべき問題は何ですか？」という質問に実際に答えた人は誰もいませんでした。だから私はそれをやってみます。

次の場合は、インメモリデータベースを検討する必要があります。1。ターゲットシステムに管理するデータはあるが、永続メディアがない2.永続データベースではパフォーマンス要件を単純に満たすことができない

＃1については、セットトップボックス（STB）のTVガイドについて考えてみてください。ローエンドSTB（つまり、DVR機能のないもの）には永続ストレージがなく、永続ストレージも必要ありません。しかし、400チャンネルの14日間のTVガイドのデータベースは重要です。ここでもパフォーマンス要件があります。これは、データがトランスポンダーカルーセルから高速で到着し、「キャプチャするか、カルーセルが再び表示されるまで待つ」場合であるためです。しかし、永続性は必要ありません。私たちは皆これを見てきました。自宅で電源が切れたとき、TVガイドに戻ったとき、トランスポンダまたはケーブルヘッドエンドから自分自身をプロビジョニングしているため、「まもなく利用可能になります」と表示されます。ネットワークルーターは同じ特性を共有します。永続的なストレージがなく、高速である必要があります。

＃2の例は無限にあります。軍事システム、高頻度取引システムなどでのリアルタイムターゲティング。

質問の2番目の部分である「注意すべき問題」に関して：たくさんあります。

インメモリデータベースのみが提供できるパフォーマンスが必要な場合は、真のインメモリデータベースを評価していることを確認してください。永続データベースのキャッシュは同じではありません。RAMドライブに永続データベースをスローすることは同じではありません。本質的にトランザクションログを実行するインメモリデータベース（TimesTenなど）を使用することは同じではありません（/ dev / nullにログを記録する場合でも）。

単なるキャッシュ（memcacheなど）ではなく、データベースシステムを評価していることを確認してください。データベースシステムは、ACIDプロパティ、複数のインデックスオプション、同時アクセスのサポートなどを備えたトランザクションをサポートします。

ACIDについて：インメモリデータベースシステムには「D」（耐久性）がありません。それは単に文脈の中でとらえられなければなりません。永続データベース内のトランザクションは、それが保存されているメディアが耐久性がある場合にのみ耐久性があります。同じことがインメモリデータベースにも当てはまります。いずれの場合も、耐久性を重視する場合は、バックアップを作成することをお勧めします。

于 2012-12-05T23:59:31.717 に答える
5

傾向は、積極的にキャッシュし、データベースを使用してキャッシュにデータを投入することです。データベースが存在する場所に関係なく、結合は依然として高価であるため、結合を1回実行し、結果をMemcachedやVelocityなどにキャッシュすることが優先されるようです。

インメモリデータベースはまだ存在し、使用されていますが、使用するコンテキストによって異なります。たとえば、SQLiteは、データレイヤーをテストするときにインメモリデータベースとしてよく使用されます。

于 2009-10-20T10:52:07.740 に答える
5

ほとんどの場合、従来のデータベースの完全な代替品として使用できるメモリ データベースの成熟した製品はありません。

リレーショナル データベースは非常に古い概念です。前進し、新しい技術を開発するための多くのアプローチがありましたが、例えば。オブジェクト指向データベースとは異なり、リレーショナル データベースの概念は実際には変わりませんでした。過去 10 年、15 年、あるいはそれ以上、データベースはあまり変化していないため、物事が急速に変化するとは思わないでください。

テクノロジーの開発は、人が信じているほど速くはないと思います。新しい概念が成熟して確立されるまでには数十年かかります。まず第一に、成熟度が他の何よりも重要なデータベース技術です。

10 年か 20 年後には、データベースはおそらく現在と同じではなくなっています。インメモリ データベースが未来であるとすれば (今日は誰にもわかりませんが)、開発にはもう少し時間が必要です。

于 2009-10-21T08:39:23.243 に答える
4

最も重要な理由は、貨物文化とITの知識レベルが非常に低いことです。ほとんどのアプリケーションは、使用する永続化ソリューションが何であれ、十分に機能します。コンピューターは毎年高速化されているため、十分な数の人が苦痛を感じず、問題を特定できません。

マイクロソフトとオラクルは、データベース製品で多額の収益を上げているため、（政治的に）より良いアプローチを考え出すことができません。

リレーショナルデータベースを使用するための開発コストは透過的にされていないため、管理者は解決策は言うまでもなく、問題があることを認識していません。

于 2011-08-28T15:43:12.037 に答える
2

一般に、インメモリ データベースには、その性質上、 ACID (原子性、一貫性、分離、耐久性) のD (耐久性)が欠けています。これは「ハイブリッド」アプローチである程度克服できますが、耐久性の側面を提供するために、ある時点で何か (データ自体またはトランザクション ログ) をどこかに永続化する必要があります。これにより、通常、パフォーマンスが低下したり、インメモリ データベース ソリューションに他の望ましくない特性が導入されたりする可能性があります。

対照的に、今日の RDBMS のほとんどは ACID を完全に補完しており、その背後には何十年にもわたる開発が行われています。これにより、非常にパフォーマンスの高いディスクベースのデータベース システムが生まれました。特に、現代の RDBMS システムで見られた長年の改善と最適化が行われています ( BTreeの例は多くの例の 1 つにすぎません)。

もう 1 つの要因は、アプリケーション開発者がキャッシングなどのメカニズムによってデータベースの負荷を軽減し、アプリケーションのデータ レイヤーからより多くのパフォーマンスを引き出すことができることです。実際、キャッシング自体は、最近では分散キャッシングが一般的になっているため、ここ数年で大規模な開発が行われています (たとえば、 memcached のユーザー数を見てください)。

皮肉なことに、現代のキャッシング システムは、多くの点で、真のインメモリ データベース システムに似たものにゆっくりと変化しています。オブジェクト指向データベースと同様に、インメモリ データベースはまさに「ブロック上の新しい子供」であるため、これらすべてが時間の経過とともにどこに行くのかを見るのは興味深いでしょう。Oracle は現在 TimesTen を買収しており、このウィキペディアの記事によると、Microsoft はすぐにインメモリ データベース市場に参入することを検討しています。これは、インメモリ データベース システムを真剣に考えている、従来の RDBMS 分野における現代の 2 つの「ビッグ プレーヤー」です。

于 2009-10-20T10:58:03.993 に答える
1

これもオプションです: http://www.memsql.com/

個人的に使用したことはありませんが、MySQL インメモリのドロップイン代替品のようなものだと思われます。

于 2013-03-15T02:57:45.140 に答える
0

データベースの最も一般的な使用例は永続性であり、ほとんどのインメモリ データベースは不適切です。インメモリ データベースを使用する一般的な理由の 1 つは、テスト目的です。ただし、これには、インメモリとその他の両方として設定できるデータベースのいずれかを使用する必要があります。

この分野で人気のある選択肢は、.Net 開発者向けの RavenDB と Java 開発者向けの OrientDB のようです。どちらもメモリ内データベースとして機能し、構成に応じて「その他」として機能するため、構成に応じてどちらか一方を使用できます (.Net の app.config、Java の Maven または Ant 設定)。

于 2013-03-15T10:58:21.940 に答える
0

主にモバイルデバイス向けに設計された、同じ効率で動作する SQL のさまざまなポータブルバージョン。

SQLite

SQL Server コンパクト エディション

これらは単なる大物プレーヤーであり、他のオプションがあるかもしれませんが、大物プレーヤーはそれをリリースすることで最小要件を処理します.. :)

また、メモリデータベースでは、変動や停電が発生した場合にデータを継続的にバックアップしているため、全体が失われる可能性があります. 他のものと同様に二次記憶装置(HDD)にあるものとして扱われ、失われる可能性は記憶DBと比較して10%になります。

これが役立つことを願っています:)

于 2013-03-15T10:43:04.253 に答える