2

多くの制約を受けて、最適なシフト割り当てを自動的に見つけるプログラムに取り組んでいます。私はgrailsを使用しています。つまり、ワーカー、シフト、割り当てに関するデータは DBMS に保存されます。

最適化自体については、データの小さなサブセット (約 5 つの異なるテーブルから合計約 600 行) に対して非常に集中的に作業する必要があります。さまざまなサブサブセットを何十回も反復して検索し、フィットネス関数を計算し、いくつかの値を変更し、フィットネスを再度計算し、泡立て、すすぎ、繰り返し、おそらく何百回も行う必要があります。

さて、検索と反復はまさに DBMS の目的ですが、この場合、HSQLDB のようなインメモリ DBMS であっても、何百もの DB 要求のオーバーヘッドが実際に行われる作業を小さくすると思います。代わりに、最初にサブセット全体をメモリに丸呑みし、実行する必要があるルックアップ用に独自のインデックス (主に HashMap) を構築し、それらのみを使用して、DB から離れて作業することを計画しています。完了し、結果を書き込みます。

これは健全なアプローチですか？より良いアイデアはありますか？

4

1 に答える 1

1

I'm assuming you must issue hundreds of commands to the database? There's no way to execute the code inside the DB?

The main thing I'd be worried about is integrity; make sure you handle locking correctly. You'd probably want a version number stored somewhere so you don't need to lock the entire set of data for the duration of processing. In the update transaction, you'd first ensure the version number is the same as when you started reading.

Finally, benchmark it? I've done some apps over the last year or so that had a similar very intensive compute process per request. Using in-process objects to represent the data was orders of magnitude more efficient than hitting the database per request. But every app is different and there might be things not considered that'll impact it.

于 2009-04-02T09:45:53.910 に答える