スモールトーク/シーサイドでのデータ永続性

Question

最近、スモールトークとシーサイドに知り合ったことがあります。私はJava EEの世界から来ています。あなたが想像しているように、Smalltalkの概念のいくつかの周りに私の考えを引きつけるのは難しいことです。 :)

現時点では、データの永続性がSmalltalkの世界でどのように実装されているのかを把握しようとしています。 Javaプログラマとしての私の前提は、RDMS（すなわちMySQL）とORM（すなわちHibernate）を使用することです。私はSmalltalk（少なくともHibernateを使用している）ではそうではないことを理解しています。私は必ずしもJava EEでのやり方に最も密接に関連した方法を模索しているわけではありません。

イメージをオブジェクトストアまたはRDMSに保存するのが最も一般的ですか？ SmalltalkのアプリケーションでRDMSを使用するのは一般的ですか？

私はここには一通りのアプローチはなく、正しい永続化戦略はアプリケーションのニーズ（データ量、並行性など）に依存することを理解しています。シンプルではあるが規模を拡大する良いアプローチは何ですか？

私はAvi BryantのvideoがDabbleDBの永続性とスケーリングに使用した戦略について議論しているのを見ました。私が理解しているところでは、顧客のデータは画像の右側に保存されていました（顧客ごとに1つの画像）。顧客はデータを共有する必要がなかったので、彼のユースケースではうまくいきました。これは一般的なアプローチですか？

私はこのTLDRを作成しませんでした。 Smalltalkの皆さんが私の以前の質問で提供した洞察に感謝します。それは感謝しています。

Answer 1

ジャスティン、

心配しないで、Smalltalkのは、この分野で非常に異なるフォーム他の言語ではない、それだけでイメージベースの永続性オプションを追加します。

Hibernate for SmalltalkのようなO/Rマッパーがあります。GLORPとそのPharoポートDBXtalkは、最近人気のあるものです。あなたがHibernateを知っていれば、これらはあなたにとって非常に快適に感じるはずです。

次に、GemStoneやMagma DB、VOSSなどのOODBソリューションがあり、O/Rマッピングの問題をすべて解決できるようになっています。これらのほとんどはSmalltalkオブジェクトの格納に限られています.GemStoneはRubyや他の言語にブリッジを提供する際の例外です。

CouchDB、Cassandra、GOODSなどの最新のNoSQLデータベースにSmalltalkオブジェクトを格納するツールもあります。ここでのトリックは、Smalltalkのオブジェクト値をJSONストリームに変換し、HTTPリクエストを少しだけ行うことです。

最後に、完全なSmalltalkイメージを保存するオプションがあります。私はあなたがそれを実稼働環境で行うことができると言いますが、それは多くの人々のための標準的な方法ではありません。開発時には多くのことを行います。保存したときと同じように、イメージを保存して次回にすべてのオブジェクトを正確に再開できるためです。

ベースラインは次のとおりです。あなたが知っているすべてのストレージオプションもSmalltalkでも利用できます。

ヨアヒム

Answer 2

私はそれは基本的にあなたのDBは、になるだろうと、それは負荷の種類を処理する方法に大きな依存すると思います。

私の場合、私が書いたすべてのアプリケーションは、ディスクのシリアル化でイメージの永続性を使用します。基本的には、要求に応じてFuelを使用してオブジェクトをシリアル化します。私の場合は、重要なデータが処理されるたびに毎回それを行います。さらに、24時間ごとにシリアル化する定期的な処理も行います。画像は24時間ごとに自動的に保存されます。

私はこのアプローチを使用して書いて最大のアプリケーションでは、一年半のために毎日それを使用している10人の労働者に加えて、約50フリーランサーの小さな会社のすべてのビジネスプロセスを処理しています。ワークロードは大規模なファイルを扱うアプリケーションを考慮してもかなり大きいですが、アプリケーションは安定していて高速です。新しいサーバーに切り替えてPharoイメージを更新するのは、プロジェクトをmonticelloから元に戻し、最新のシリアライズされた「データベース」を実現するのと同じくらい簡単でした。私の意見で

、ORMは不要痛みで、我々は、オブジェクトの世界にいる、と私たちは素敵なオブジェクト指向のソリューションを持っている場合は特に私たちのオブジェクトを平らにするために持つことは、単に間違って感じています。

アプリケーションがデータのかなり少量を扱うのであれば、私は私の単純なアプローチやSandstoneDBのいずれかをお勧めしたいです。あなたのアプリが膨大な量のトランザクションとデータを扱うなら、私はGemstoneに行くだろう。

ちょうど私の2セントです。

Answer 3

ラモン・レオンは、状況、基本戦略、およびそのトレードオフ美しくin his blog postを説明しています。私は彼のシンプル・イメージベースの永続化フレームワーク、I portedで始まり、ファーロ1.3で使用することになり

。 Mariano Martinez Peckは最近、燃料（同じリンク）を使用するように改造しました。それは非常にシンプルであり、仕事をしてくれて、自分のイメージで遊ぶことにもっと自信を持っています。永久に損傷しても、私のすべてのデータは安全です。データフォルダを新しいイメージフォルダにコピーし、パッケージを読み込み、すべてのオブジェクトが新しいイメージに生きているだけです。