7

現在、代替データ ストアの概念実証を開発中です。その理由は、ほとんどが読み取り専用のクラスター化された webapp を拡張する必要があるためですが、時には過度に複雑な ORM+RDBMS ソリューションの苦痛から解放されたいからでもあります。

全体的な考え方は、永続性を備えた分散キャッシュ(クラスターを SoR にする)と非常によく似ていますが、次のようになります。

  • ID（クラスとIDを提供する）によって、その子とともに任意のオブジェクトを取得できるようにしたい[メインのクエリ部分はすでにアプリのluceneで解決されているため、開始するだけ]。
  • タイプのマップのマップ (リレーショナルな世界では ~ テーブル) が必要であり、そこには「脱水された」格納オブジェクトの分散マップ (リフレクション ディープ クローニングによるオブジェクト グラフの平坦化) が必要です。
  • ビンログ (Prevayler など)
    • クラスター全体がダウンした場合の最終的な回復
    • 開発 (およびコードをリファクタリングする能力 / 構造を変更する能力)
    • おそらく他の目的（レポートなど）のために非同期に処理されます
  • 最終的には、LINQ、Jaque、H2 の JaQu などの静的に型指定されたクエリ メカニズムの統合を試みます / ODB を参照 / Lucene (?)
  • トランザクションに対応している必要があります（ただし、「JTAタイプ」は不明です）

このアイデアを Hazelcast (非常にシンプルな API が気に入っています) または Terracotta (使用したことはありませんが、それらの「スイート スポット」である中期データは認識しています) を使用して実装する予定です。もしよろしければ、私の目標は多かれ少なかれジョナスがかつてブログで書いたことをすることです。これらのいずれかを使用すると、格納されたデータはクラスターの JVM ヒープの合計にほぼ収まる必要があります。

これはスケーリングが非常に簡単で、リレーショナル インピーダンスの不一致 (ODB のように保存) と JDBC + I/O オーバーヘッドを回避できます。

私が無視している他のツール/フレームワーク、またはそれらの組み合わせがすでに同様の機能を提供していることを知っていますか? この「DB を取り除く」ことに取り組む他の方法を提案できますか? このアイデアには、すでにどのような欠陥がありますか? 並行性に関しては、Java の代わりに Scala を検討することは理にかなっていますか?

Couch DB、Neo4j、HyperTable、HBase などの非リレーショナル データ ストアはどうですか?

同様の質問が 1 か月前に行われましたが、具体的な解決策はありませんでした。

ところで、エンタープライズ データ ファブリックの概念に出くわしましたが、驚いたことに、これらのアイデアの多くが説明されています。

4

6 に答える 6

2

質問でNeo4jが言及されているので、この場合にグラフデータベースを使用することについていくつか考えています。(私は Neo4j チームの一員です)

  • 子の取得は、グラフ db では簡単です
  • neo4j のマップ実装があります
  • グラフはグラフ db にネイティブであるため、オブジェクト グラフを平坦化するのではなく、ノードとエッジ/関係にデータを保持することを検討できます (これにより、データをより柔軟に処理できます)。
  • neo4j は完全にトランザクション対応です

現在、新しい DB テクノロジが出現しているため、データがリレーショナル パラダイムに適していない場合、RDBMS にとどまる必要はまったくありません。

于 2009-01-08T12:36:33.377 に答える
2

私には Terracotta があなたの要求に完璧に合っているように思えます:

  • キーを介して子を取得するためのマップをクラスター化します (例: クラスター化されたマップ)
  • マップのマップ - 問題ありません
  • 明示的な bin ログはありませんが、Terracotta はすでにすべてをディスクに保存しているため、クラスターの完全な再起動は既にサポートされています
  • Compass、Hibernate Search、検索用の Lucene に統合済み
  • 取引？遅すぎる。キャッシュをデータストアとして使用します。永続性を使用すると、(クラスター化された) メモリへのデータ書き込みが失われず、DB に少しずつ戻ってきます。

さらに、Terracotta は要求された "反射" を実行しますが、反射は遅すぎるため使用しません。BCMを使用しています。変更のみがネットワーク上に伝播されます。

Hazelcast btw はシリアライゼーションを必要とするため、速度が遅くなり、maps データ構造のマップではまったくうまく機能しません (すべての配置により、ネットワーク全体で完全なディープ クローン コピーが作成されます)、永続性が組み込まれていません。 .

于 2009-01-27T07:02:06.493 に答える
2

テラコッタをぜひお試しください。無料です (SLA とサポートを備えた Enterprise に移行しない限り)。いわばJVMレベルのクラスターなので、異なるJKワーカーの背後にある複数のボックスでのセッションに関連する問題はありません(これをJ2EEアプリに使用していると仮定します)。

私はとりとめのないので、ここを見てください: http://en.wikipedia.org/wiki/Terracotta_Cluster

Web 上の Terracotta に関する多数の情報も更新してください。

更新2私の見解の背景: 私はかなり多くの聴衆を持つ会社で働いています。MySQL の JDBC レプリケーション ドライバー (既にさまざまなパッチを提出済み) を使用して、マスターと約 5 つのスレーブ (チャネルが 2 つあり、チャネルごとに 4 つのアプリ サーバーがあることを考えると 2 倍) で実行されているエンタープライズ MySQL があります。Spring の宣言型 JTA トランザクション管理を使用して Spring2.5/Hibernate3 を使用するため、読み取り専用はスレーブに行きます。サイトの将来のバージョンで多数の Ajax 拡張機能が登場したため、DB サーバーの負荷が増加しました。これらすべての国の関税/税規則 (およびプロモーション) を考慮して、すべての国の数千の製品の価格概要を作成します。常に実行されているリアルタイムのオークション)、Ajax サービスは最新の価格を瞬時に取得します。Terracotta は、ボックス全体のすべての JVM がリンクされた JVM レイヤー上のすべてのアプリ サーバーでこれらの価格を利用できるようにすることで、DB とアプリ サーバーの負荷を軽減します。したがって、サーバー A は数分ごとに価格を更新でき、Ajax がサーバー B にヒットすると、価格はすぐに利用可能になります。おそらくより良いアイデアと実装を持っている、同様のビジネスを持つ人々/企業がそこにいることを私は知っているので、私は常に議論の余地がありますが、これは私の2セントです.

Facebook の人たちからもインスピレーションを得ています。たとえば、この非常に有益な記事: http://www.facebook.com/note.php?note_id=23844338919

彼らはmemcachedについて話しているので、ぜひチェックしてみてください。

于 2009-01-06T22:50:56.553 に答える
1

面白い。

私たち全員が、プロジェクトで習慣的に使用するすべての抽象化レイヤーを含む動物園を開発していると考えています。そして、各抽象化レイヤーは完全に異なる動物です。

私の目標は、目の前の問題を解決することから私をそらすときはいつでも、動物の世話と給餌に費やされる時間を最小限に抑えることです-それはオーバーヘッドです-無駄なリソース. したがって、抽象化レイヤーが少なくて単純なほど、生産性が向上します。

私は通常、OOP と RDBMS という 2 つの野獣をうまく使いこなすことができます。これらは、素晴らしくシンプルで最小限の手作りの DAL を介して結合されます。私にとって、ORM は主にオーバーヘッドです。1 つの抽象化が多すぎて、かなり空腹です。

ストアド プロシージャを抽象化ツールとして扱うという選択肢も軽視しないでください。SQL に慣れている場合は、ORM の問題について考える必要がない軽量の BL ファサードを実装するための便利なリソースになる可能性があります。

とにかく、この投稿は、いくつかの要件に対して RDBMS に代わるものの出現を示唆しています。

于 2009-01-06T23:10:25.093 に答える
0

回答ありがとうございます。

実際、あなたは DB について話していますが、これは私が完全に排除したいものです。

私が対象としているユースケースは、スタートアップの小規模/中規模のクラスター化された webapp (LAN またはクラウド内のボックス) です。~RAM の速度レベルでオブジェクトを取得し、かなり簡単にスケーリングする必要があります。副作用として、DB サーバーのインストール、インピーダンスの不一致、JDBC、キャッシュ、アノテーションによるドメイン モデルの汚染などについて考える必要がなくなります。

繰り返しますが、私が達成したいことは、ここで説明されているようなものであり、実際の実装に関するアイデアについて、さらにフィードバックをお待ちしています (Hazelcast の代わりに Terracotta を使用する理由、リフレクションによるシリアライゼーションまたはディープ クローニングなどを使用する理由、およびこのようなアプローチの主な欠点 - たとえば、なぜ現在の ORM/DB セットアップに合わせて変更しないのですか)。

コードの可読性を向上させる、非常にきちんとした Java API を備えているため、統合は非常にシンプルでなければなりません。他のソフトウェアは必要ありません (DB、memcached が必要になります)。

于 2009-01-07T12:38:51.297 に答える