本家記事の末尾 「The documentation says that MemSQL writes back to disk/SSD as soon as the transaction is acknowledged in memory,
and that using a combination of write-ahead logging and snapshotting ensures your data is secure.
There is a free version but so far how much a full version will cost isn't given.」 も入れとかないと、そういうコメントだらけになりそうですよ。
「The documentation says that MemSQL writes back to disk/SSD as soon as the transaction is acknowledged in memory,
and that using a combination of write-ahead logging and snapshotting ensures your data is secure.
There is a free version but so far how much a full version will cost isn't given.」
黄緑のうちに、とり急ぎコメント (スコア:5, 参考になる)
本家記事の末尾
「The documentation says that MemSQL writes back to disk/SSD as soon as the transaction is acknowledged in memory,
and that using a combination of write-ahead logging and snapshotting ensures your data is secure.
There is a free version but so far how much a full version will cost isn't given.」
も入れとかないと、そういうコメントだらけになりそうですよ。
名前に反して、ちゃんとディスクに書き込むしデータ保護もしている。
フルバージョンの値段は未公開。
Re:黄緑のうちに、とり急ぎコメント (スコア:0)
要するに一言で言うと、SQLコンパイラ？
Re:黄緑のうちに、とり急ぎコメント (スコア:2)
Re: (スコア:0)
違うよ。
データはメモリ上に持つけれど、トランザクションはちゃんと保証されるってことでしょう。
つまり元コメの
＞ちゃんとディスクに書き込むしデータ保護もしている。
がすでに一言で言っています。
どう読んで「SQLコンパイラ」なんて言葉が出てきたのだ？
Re: (スコア:0)
こういうタイプの作りだと、OSが死んだときに、SSDに書き込めてないデータが消えそうなんですけど
その辺はどうしてるんでしょうかね。
Re:黄緑のうちに、とり急ぎコメント (スコア:3)
Re: (スコア:0)
普通のDBでもOSが死んだりしてcommitできなければ
消えるのは当たり前。
Re: (スコア:0)
Linuxはそのあたりの実装がいい加減だったそうですが、今もそうかな？
commitできないなんてのはアプリレベルの話です。
Re: (スコア:0)
OSはディスクに書き込んだつもりでもHDDのキャッシュに乗っただけとか
Re:黄緑のうちに、とり急ぎコメント (スコア:3)
HDDの制御基板のキャッシュに関しては、電源OFFの際にもコンデンサにたまってる電荷で稼働できる最後の数10msで書き込んでくれるんじゃなかったっけ？
Re: (スコア:0)
それでも問題ないでしょ？
Re: (スコア:0)
っていうか、OSが落ちただけなら全然問題無いよね。
Re: (スコア:0)
> どう読んで「SQLコンパイラ」なんて言葉が出てきたのだ？
「SQL 文を最適化された C++ コードに変換して」の辺り。
というか、どう読んでデータの置き場所やトランザクションの話が出てきたのだ？
Re: (スコア:0)
「The documentation says that MemSQL writes back to disk/SSD as soon as the transaction is acknowledged in memory,
and that using a combination of write-ahead logging and snapshotting ensures your data is secure.
There is a free version but so far how much a full version will cost isn't given.」
のどこに
「SQL 文を最適化された C++ コードに変換して」
って書いてあるんだ？
Re: (スコア:0)
落ち着いてタレコミ文から全部読み直すといいと思う
Re: (スコア:0)
わざわざこのスレッドにぶら下げるいいわけにはならないなあ。
Re: (スコア:0)
そう書いてあるからには、I/Oをサボって（手抜きをして）高速化してるわけじゃないんだな、と思ったわけよ。
とすると、タレコミにある「変換して」の部分がキモかな、と思ったわけよ。
なんかおかしい？
原理を正しく見抜いているかではなく、話の進め方が。
Re:黄緑のうちに、とり急ぎコメント (スコア:2)
おおまかな話の流れとしては理解できるんだけど、
は誤訳というか前後が逆ですね。
「実行速度の最適化のために、SQLをC++コードに変換している」のであって、
「最適化されたC++コードに変換している」わけではないでしょう。手段と目的が逆。
データベースのデータを全部オンメモリにすれば格段に高速化できる。
でも、検索処理における個々のレコードについての条件比較で、SQLをインタプリタ実行していては無駄。
こういう場合の処理の定番は「JITコンパイル」ですね。比較処理部をネイティブコードにすればいい。
で、そのコンパイル手段として、SQL→C++のトランスレータにしているということなのでしょう。
自前でSQLをネイティブコードに落とすコンパイラを作るのが一番でしょうけど、そうするのはかなり難易度が高いでしょう。
それに比べると、
SQLのデータ型をC++のクラスに対応させられれば、SQL→C++は比較的簡単に変換できると思います。
単にネイティブコードになるだけでも格段に速くなるでしょうし、
C++コンパイラの最適化の恩恵によってさらなく高速化も期待できます。
#SQLの文字列比較が、C++のクラスオブジェクトの比較を経由して、コンパイラビルトインのstrcmpになるとか、そんな感じ。