私は本当に SimpleDB を使いたいのですが、本当のロックとトランザクションがなければ、システム全体に致命的な欠陥があるのではないかと心配しています。最終的にシステムが一貫するようになるため、高読み取り/低書き込みアプリの場合は理にかなっていることは理解していますが、その間の時間はどうですか? 一貫性のないデータベースでの正しいクエリは、追跡が非常に難しい方法でデータベース全体に大混乱をもたらすようです。うまくいけば、私はただの心配いぼです...
jcapote
質問する
1002 次
2 に答える
4
これは、一貫性とスケーラビリティ、およびある程度の可用性の間のかなり古典的な戦いです。一部のデータは、必ずしも一貫している必要はありません。たとえば、digg.comとストーリーに対するdiggの数を見てください。DBに「user_digg」テーブルに対して結合を強制するのではなく、「digg」レコードに値が複製される可能性が高くなります。その数が完全に正確でなくても問題ありませんか？おそらくそうではありません。次に、SimpleDBのようなものを使用するのが適切かもしれません。ただし、銀行システムを作成している場合は、おそらく何よりも一貫性を重視する必要があります。:)
初日から大規模な処理を行う必要があることを知らない限り、RDBMSのような単純で従来型のシステムに固執します。合理的なビジネスモデルでどこかで作業している場合、トラフィックが大幅に増加すると、収益が大幅に増加することを願っています。次に、そのお金を使ってスケーリングの問題を解決することができます。スケーリングは難しく、スケーリングを予測するのは困難です。あなたを傷つけるスケーリングの問題のほとんどは、あなたが予期しないものになるでしょう。
私はむしろサイトを立ち上げて、トラフィックが増加したときに規模の問題を修正するために数週間を費やし、その後、資金が不足しているために本番環境に到達できないほど規模について心配することに多くの時間を費やしたいと思います。:)
于 2008-11-29T08:22:04.003 に答える
0
この SimpleDBについて話していると仮定すると、あなたは心配症ではありません。実際の DBMS として使用しない本当の理由があります。
DBMS のトランザクション サポートから得られるプロパティは、"ACID" という頭字語で表すことができます: 原子性、一貫性、分離、耐久性。A と D は主にシステム クラッシュに関するもので、C と I は通常の操作に関するものです。これらはすべて、商用データベースを操作する際に当然のことと考えられているものです。そのため、それらが 1 つ以上含まれていないデータベースを操作すると、多くの厄介な驚きに遭遇する可能性があります。
Atomicity : トランザクションは完全に完了するか、まったく完了しません (つまり、正常にコミットまたは中止されます)。これは、単一のステートメント ("UPDATE table ..." など) だけでなく、より長く複雑なトランザクションにも適用されます。これがないと、何か問題が発生した場合 (ディスクがいっぱいになる、コンピューターがクラッシュするなど)、何かが中途半端なままになる可能性があります。言い換えれば、DBMS に指示したことを実際に実行することを DBMS に依存することはできません。実際の問題はいくらでも発生する可能性があり、単純な UPDATE ステートメントでさえ部分的に完了してしまう可能性があるからです。
一貫性: データベースに関して設定したルールは常に適用されます。たとえば、A が常に B に等しいというルールがある場合、データベース システムに対して何をしてもそのルールを破ることはできません。試行した操作はすべて失敗します。すべてのコードが完璧である場合、これはそれほど重要ではありません...しかし、実際にそうである場合はいつでしょうか? さらに、このセーフティネットを逃すと、負けたときに事態は非常に厄介になります...
分離: データベースで実行されるすべてのアクションは、実際には同時に発生している (相互にインターリーブされている) 場合でも、連続して発生したかのように (一度に 1 つずつ) 実行されます。複数のユーザーが同時にこのデータベースにアクセスしようとしていて、これがないと、思いもよらないことがうまくいかなくなります。アトミックなステートメントでさえ、予期しない方法で相互に作用し、物事を台無しにする可能性があります。
耐久性: 電源が失われたり、ソフトウェアがクラッシュした場合、進行中のデータベース トランザクションはどうなりますか? 耐久性がある場合、答えは「何もありません。すべて安全です」です。データベースは、「元に戻す/やり直しログ」と呼ばれるものを使用してこれを行います。このログでは、データベースに対して行ったすべての小さな操作が最初に (通常は安全のために別のディスクに) ログに記録され、障害後に現在の状態を再構築できるようになっています。それがなければ、上記の他のプロパティは何の役にも立ちません。なぜなら、クラッシュ後に物事が一貫性を保つことを 100% 確信することは決してできないからです。
これらのうち、あなたにとって重要なことはありますか? 答えは、実行しているトランザクションの種類と、失敗した場合に必要な保証に関係しています。これらが必要ない場合 (読み取り専用データベースなど) もあるかもしれませんが、重要なことを始めて何か悪いことが起こるとすぐに、それらがあればいいのにと思うでしょう。予期せぬ事態が発生したときはいつでもバックアップに戻せばよいのかもしれませんが、そうではないと思います。
また、これらの保護をすべて削除しても、データベースのパフォーマンスが向上するとは限らないことに注意してください。実際、それはおそらく逆です。これは、実際の DBMS ソフトウェアにも、クエリのパフォーマンスを最適化するためのコードが大量に含まれているためです。そのため、SimpleDB で 6 つのテーブルを結合するクエリを作成する場合、そのクエリを実行するための最適な方法を見つけ出すと想定しないでください。商用の DBMS がインデックス付きハッシュ結合を 0.5 秒で取得します。クエリのパフォーマンスを最適化するためにできる小さなトリックは無数にあります。
これはどれも、SimpleDB を攻撃することを意図したものではありません。このソフトウェアの作者は次のように述べています。
于 2008-11-29T13:39:08.137 に答える