【オンメモリ%メモリデータベース【インメモリ】

**NAME IS NULL** · 2006/01/27(金) 22:24:34

オンメモリRDBに関するスレッドが無かったので立ててみました。

従来のディスク上にデータを置かず主メモリに置くことで
I/Oコストを減らすアプローチを採用したことから性能面で勝るようです。
今後64bitCPUが広まるにつれ扱えるデータ容量も増えるだろうから
選択肢として気になる所です。
まだまだ認知度も低いですが今後の動向に期待。

以下紙面でよく見かけるオンメモリDB

・Oracle TimesTen In-Memory Database
・MySQL(HEAP table)
・DayDala.Boo
・高速機関
・Kairos

**NAME IS NULL** · 2006/01/27(金) 22:26:06

いきなりスレタイトル失敗したよ orz

【オンメモリ】%メモリデータベース【インメモリ】
ってしたかったのに。

**NAME IS NULL** · 2006/01/28(土) 00:48:56

JavaのHSQLやDerbyもそういうモードあったな

**NAME IS NULL** · 2006/01/28(土) 11:49:33

MySQLってDBマガジンにのってた使い方？
使ったこと無いからよくわからん
実際どうなの？

**NAME IS NULL** · 2006/01/28(土) 14:04:24

Prologのassert,retract,abolishでやってますが、
データベースシステムでないからだめですか？

600万件を超えてる売上データ(これはPostgresql)以外は、
何台かのマシンに分散させて、Prologインタプリタで
定義節として管理させています。停電に備えて、一分ごとに
全てのマシンでProlog環境のバックアップを取るということが
特徴かな。

同時更新が絶対に起こらない業務体制なので可能ということですが。

**NAME IS NULL** · 2006/01/28(土) 23:55:29

>>5
ちなみに
assert = INSERT
retract = UPDATE
abolish = DELETE ですね？

いきなり異色なテーマが出てきてびっくりしました。
SQLをサポートしていないオンメモリDBもあるのでPrologもありかと。

確かDayDa.Labooが独自APIでSQLをサポートしていなかった筈。

**NAME IS NULL** · 2006/01/29(日) 10:34:41

なつかしー。
Windows 2000の発表の頃 "In-Memory Database" IMDB
があったけどポシャったよね。

**NAME IS NULL** · 2006/01/29(日) 11:17:11

IMSBでぐぐったらインターネットムービーDBが多数hit

IMDBこれかな？
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdndna/htm/page16.asp

**NAME IS NULL** · 2006/01/29(日) 13:35:03

いやこれこれ。IMDBはボツにしましたって珍しいページ。

What Happened to IMDB?
http://msdn.microsoft.com/library/en-us/dncomser/html/whatimdb.asp

**NAME IS NULL** · 2006/01/29(日) 22:34:41

>>9
面白いドキュメント読ませていただきましたｗ

**NAME IS NULL** · 2006/02/01(水) 22:46:19

i-RAM使えばどれでもオンメモリデータベース。

5 · 2006/02/03(金) 12:10:57

Prologをデータベースとする場合の構成だけ述べておきます。

Prologはサーバーとして動作します。他のタスクからPrologへの
接続はTCP/IP経由で定められたポート番号を使います。
一般にサーバーは要求があると子タスクをfork()して、
自らは次の要求を受け入れる準備をするものですが、
私の所のPrologデータベースでは、要求が完結するまでは
次の要求を受け入れません。
ただし、このような、ブロックが必要なのは、データベースの
追加、更新、削除の時だけです。破壊代入がPrologには
存在しないため、それ以外の実行はfork()された子タスクで
あって構いません、副作用は生じません。

したがって、assertzの代わりデータベースアドレス+ポート番号付きの
db_assert、retractの代わりにdb_retractを全ての
Prologシステムに準備して、この述語の実行(副目標という)の時のみ、
サーバーを参照すれように定義しておきます。

db_*** 述語の時のみ、サーバーはfork()なしでデータベースの
更新作業を行う事になります。データベースの参照もまたdb_** で
行わないといけません。他のネットワークノードからのサーバーの
述語定義を利用して実行したい時は子タスクをサーバーはfork()する
のですが、fork()された子タスクのPrologデータベースは
更新前のデータベースをもっていますから、これを参照してしまうと
誤謬を生じます。必ず全て、db_***で呼びださないといけません。
ここら当たりにこのシステムの陥穽があります。

UNIXのようなマルチタスクOSではTelnet接続でいくつかの
Prologが同時に動作することがあります。このような場合でも
原則としては、1システムに1Prologサーバーを用意しておけば、
データベースを通じてこれらのProlog間のデータの同期を取る
ことが可能になります。

**nikkei crub** · 2006/02/06(月) 17:13:27

◆ On Memory（一般にはIn Memory）という言葉に飛びついてはいけません。
学生が実験室で横のものを縦にして、ある特定の条件で性能が高くなると
いう事実を発見したからと言って、実業の分野ですぐ取り入れるのは、
余程の趣味人かその道の研究者でもない限りあり得ないでしょう。

◆ On Memoryはターボデータの場合、縦に情報を捉えて、独自のデータ形式、
独自の集合のアルゴリズム（LFM技術）で処理しているので、習熟した
エンジニアで、かつ特定の条件でなければ期待するパーフォーマンス
は得られません。　このエンジニアの育成には半年以上掛かり、教育投資が
必要になります。この製品を使いこなすコストは無視でない筈です。　
ターボデータのDayDa.Labooエンジンのユーザの約半数は、購入して導入した
ものの現在は使われていないです。

◆ 真偽のほどは分かりませんが、SAPやSUNが富士通BSCの「Oh-Pa1/3」をISV
に認定したとターボデータは言っています。　しかしISVとは、SAPやSUNは
一切責任を取らないという条件付きで、世の中には「こういうものもあり
ます」という紹介程度で、何のオブリゲーションも無いのものです。本当に
優れて実用的なものであれば、明らかに自社製品に採用している筈ですが、
採用したという話は聞いていません。
富士通は、富士通BSCという子会社で販売していますが、本腰を入れたという
訳ではないようですし、日立はRH-BOMという特定のアプリケーションで使用
しただけ。日立もRH-BOMはビジネスにはなっていないようですし、Oracleや
Microsoftは今のところターボデータには見向きもしていないようです。

◆ ターボデータの問題点
第一に使い難さが挙げられます。　プログラミングレス、マウス一つで
出来るというのは？　実際に業務に組み込むことになれば、APIは難解。
Object Orientedには程遠いものです。　CないしはC++の技術を持った
エンジニアが相当作り込まなければなりません。

第二にDayDa.Labooは、例えばSQLのような技術は使えません。　

第三にLIFITというGUIは、プログラミングに相当するMacroのドキュメント性
は全く考慮されていません。

第四に、何よりも特定の条件（SORTなど）でしかパーフォーマンスがでません。　

第五には、製品品質の問題が挙げられます。　ターボデータの商品は、
Student Codingと言われるほど製品品質が悪いようです。加えて製品の
保守や教育のサポート体制は何もありませんし、業務で使うソフトウエア
としてはNGです。

第六に、ターボデータが販売しているBI Tool Likeのパッケージの
「ザ･ターボ」（DayDa.Laboo＋Lifitのシングル・ユーズのWindowsベース
のパッケージ商品）は、クライアント・サーバ型でエンドユーザ・
コンピューティングという昔流行ったコンピューティング・スタイル
ですが、これではクライアントに金ばかり掛かってしまいます。いささか
時代遅れのコンピューティング・スタイルです。

第七に、BI Tool のターボ製品について、例えば32ビットで１Gバイト
のメモリーを搭載したパソコンで20億行もの大量のデータをどんな人が
必要としているのだろう？　　（64ビット4～16GBでマルチCPU、メモリー
シェア対応のシングル・ユースのターボを開発中で1兆行まで可能だと
発表しています。）　またそれほどの大量のデータを扱うとすれば、セキュ
リティとか別の問題が出てきます。

◆ 確かにOn Memory DBは、時代の流れであることは間違いないでしょう。　
これからもOn Memory DBは次々出てくるでしょう。この完成度の低い特殊な
エンジンがこのままで普及することは有り得ないのでは？と言うのが感想で
すが、他のOn Memory DBはどうなんでしょうか？

**NAME IS NULL** · 2006/02/07(火) 22:43:24

>>13
LIFITは体験版がダウンロード出来たから試用してみたけど
むちゃくちゃ使いずらかったね。
テーブルにテキストデータをローディングさせたいのに
なんでカラム毎にテキストファイルを分割して
１カラムずつローディングしなきゃならないのか
理解に苦しんだ記憶がある。

**NAME IS NULL** · 2006/02/07(火) 23:21:43

どこも吸収されたり別会社が別の製品にまとめあげて販売してるけど
DBエンジン単体では品質に問題ありって事かな？

◆Oracle Times-ten陣営
(Times-ten) 吸収
↓
(Oracle) http://www.oracle.co.jp/news_owa/NEWS/news.news_detail?p_news_code=1473

◆DayDa.Laboo陣営
(DayDa.Laboo) http://www.turbo-data.co.jp/
↓
(Oh-Pa 1/3) http://www.bsc.fujitsu.com/

◆高速機関陣営
(高速機関) http://www.kousokuya.co.jp/
↓
(FSSQL) http://www.fsi.co.jp/

**NAME IS NULL** · 2006/02/08(水) 01:13:15

たいていのRDBMSは、十分なメモリがあれば、トランザクションログ以外は
オンメモリも同然じゃないの？
バッチ処理で連続長時間の負荷をかける場合でないと
役に立たないんでない？

**NAME IS NULL** · 2006/02/08(水) 01:15:10

追伸
高速機関のサイトを昔見たら、i-RAMみたいなものを
トランザクションログ用に作ってて、やはりここがボトルネックか、
と思った。

**NAME IS NULL** · 2006/02/09(木) 00:44:08

>>13
LFM技術ってどんんな処理方式なんでしょう？
知ってたら教えてください。

**NAME IS NULL** · 2006/02/09(木) 00:49:19

あ、
MySQLのHEAP TABLEを使ってみた事がありますが
シャットダウンさせるとデータ消えるんですね。

正常にシャットダウンしたんだから再起動したら
データ復元してくれてもよさそうなのに。。。

**NAME IS NULL** · 2006/02/10(金) 07:42:10

TinesTenと同じでターボデータも富士通BSCの子会社になるってのが自然な流れだろうね。
それでピリオドでしょう。　でもOh-Pa1/3は3000万するんだって。　これでは売れないよ。

**NAME IS NULL** · 2006/02/10(金) 11:33:15

以前に高速屋の高速機関とターボデータのDayDa.Labooを比較したけど、
DayDa.Labooは、MemoryにLoadingするのはメッチャ遅かったね。

**NAME IS NULL** · 2006/02/10(金) 23:57:48

>>21
kwsk

**NAME IS NULL** · 2006/02/14(火) 01:13:18

>>20-21
IDが同じですよ。
そんなにターボデータを貶めたいんですか？
高速屋の関係者ですか、そうですか。

富士ソフトあべしの子会社化する不安でいっぱいなんですね。

**NAME IS NULL** · 2006/02/14(火) 15:56:02

ブハハハハッ！
いやぁ、ターボは面白いソフトだよ。　Oh-Paは知らないけど。
アルゴリズムで成功したことがない世界にチャレンジしているのだから。
どんどん使ったらいいんじゃない。世の中変わるかも。

**NAME IS NULL** · 2006/02/18(土) 22:42:12

製品やテクノロジーに関する話を聞きたい。
会社同士のしがらみとか正直どうでもいい。

**NAME IS NULL** · 2006/02/26(日) 07:26:07

NECは製品ないのですか、そうでつか。

**NAME IS NULL** · 2006/02/26(日) 10:22:05

使ったことないから語ることも無い。
でも興味はある。

雑誌を見ると結構使われているイメージがあるけど
実は全然マイナーな世界で誰も使ったことが無い？とか

**NAME IS NULL** · 2006/02/28(火) 23:31:36

>26
あるっぽい
ＮＥＣと数理技研、メモリーＤＢを利用した流通業向けソリューション事業で提携
ttp://it.nikkei.co.jp/business/news/release.aspx?i=124281

従来のＲＤＢ（リレーショナルデータベース）を利用したシステムに比べて５０～５０００倍の高速なデータ処理を可能とするメモリＤＢ
だそうです

**NAME IS NULL** · 2006/03/01(水) 00:52:58

うーん。何を対比してるのか全く意味不明なのに50～5000倍、ってのがポイントかも。

**NAME IS NULL** · 2006/03/01(水) 05:06:48

ＮＥＣは、はんばいするだけで、製造はしないのか。

**NAME IS NULL** · 2006/03/02(木) 00:42:14

日経システムインテグレーション 2006/3月号に
Times-Tes, Kairos, FSSQL, DayDa.Laboo の特集（10P)が掲載されています。
お近くに雑誌がある方は確認してみてください。

ちょっと裏事情っぽい話も出てて笑えます。

**NAME IS NULL** · 2006/03/04(土) 08:56:23

>>30 開発失敗

**NAME IS NULL** · 2006/03/06(月) 01:37:55

>>18
www.amazon.co.jp/exec/obidos/ASIN/4902721015
ただし買う価値なし。アマゾンのレビューは関係者？
横浜に住んでいるか横浜の職場/学校に通勤/通学している人は市立図書館で借りて済ませましょう。

>>1
SQLite in-memory も追加。

**NAME IS NULL** · 2006/03/06(月) 23:50:05

>>33
１８です。
情報ありがとう。探してみる

**NAME IS NULL** · 2006/03/09(木) 23:00:13

こんなテーマに興味もってるって、
みんな、昼間は何してる人なの？　ﾋｯｷｰ？

**NAME IS NULL** · 2006/03/10(金) 01:02:57

昼間はオンメモリデータベースの開発、販売に携わっています

**NAME IS NULL** · 2006/03/14(火) 23:14:15

いまＤＤＲ２－２Ｇ－ＥＣＣ付きが６万円程度、１Ｇ＝３万円。
１００Ｇ積めるシステムはあるから、メモリだけなら３００万円ですむ。
データの重複は排除する方式なら通常のＲＤＢの３倍はデータが乗る。
１レコード１ｋとして１００Ｍ件＝１億件×３で３億件は大丈夫。
速度は１００倍ぐらいは軽いらしい。この程度の容量ならばＤＩＳＫも
フラシュメモリで置き換えられそう。

**参加者募集中！** · 2006/03/15(水) 23:14:27

株式＠2ch
★★★自動売買ソフトを作ろうぜ★★★　Part3
http://live19.2ch.net/test/read.cgi/stock/1141718486/l50

**NAME IS NULL** · 2006/03/18(土) 16:17:07

Sysytem i5(iSeries/400 AS/400 S/38) は、OSそのものがこういう発想。
ハードディスクはあくまでもメモりの延長線上で不揮発性の特性を持つ領域という発想になってる。
まぁ３０年前から実装されてる事なんだが。

**NAME IS NULL** · 2006/03/18(土) 17:47:14

25-6年前にIBMのSEからこのマシンの説明を受けたときには
停電対策が課題ということだったが、現在、この問題は
どうなってますか。

**NAME IS NULL** · 2006/03/18(土) 21:59:24

UPSでの延命措置も間に合わなかった場合は
内部バッテリーでメモリの中身をHDに退避してから自己シャットダウン

**NAME IS NULL** · 2006/03/24(金) 00:52:11

は～

だめだな、この手のＤＢ

**NAME IS NULL** · 2006/03/24(金) 01:19:54

>>42
kwsk

**NAME IS NULL** · 2006/03/25(土) 14:55:22

>>40
参照専門でデータがいつ飛んでもいい用途に使えば良いじゃん

**NAME IS NULL** · 2006/03/25(土) 15:43:27

>>40
解決済み。
ＵＰＳなしで、いきなり停電してもデータ不整合は起きないよ。
起動に数時間かかることになるけど。
41の手順が動いたときは起動がそれより速くなる。
実際復旧作業は「入力しかけのデータ入れ直し」だけで、あとはひたすら待つだけだった。

最近Oracleで同じ事があったとき、DB破損、oracle再導入＆データバックアップから
復旧ってのには驚いた。

**NAME IS NULL** · 2006/03/26(日) 03:32:33

>>44
参照専用でいいなら、そんなん普通のDBをちょっとチューニングすりゃ済む話

>>45
Oracleが飛ぶ＆リカバリ不能なのはハードやOSが飛んだ場合。汎用機ならともかく
UNIX系ならいつかは止まるのも致しかたない

**NAME IS NULL** · 2006/03/27(月) 19:32:06

というか止まるの前提で運用設計するよな。

**NAME IS NULL** · 2006/03/28(火) 10:09:59

するよな
と
するなよ
で180度違うなｗ

**NAME IS NULL** · 2006/04/02(日) 23:01:24

最近メモリアクセスは急激に高速化されたけど、一般的なＤＢは
相変わらずログを書き終わらないとコミットを返せないというのが
インメモリタイプに注目が集まってる主因かな？

**NAME IS NULL** · 2006/04/02(日) 23:11:27

>相変わらずログを書き終わらないとコミットを返せないというのが
返しちゃマズいものは返さねーよ

**NAME IS NULL** · 2006/04/04(火) 01:02:05

50に激しく同意

ログどころかファイル操作が終わる前に
応答を返すメモリ型DB（げふんげふん

**NAME IS NULL** · 2006/04/10(月) 00:44:27

オンメモDB用に仮想記憶を捨てようって方向はどうかな？
そもそも幸っているのはCPU or BUS?

**NAME IS NULL** · 2006/04/10(月) 21:43:33

↑の書き込みを見て唐突に略称を思いついてしまった。

オンモDB
オンモでぶー

**NAME IS NULL** · 2006/04/10(月) 22:39:32

唐突に私も思いついた。

楽波の志賀の辛崎幸くあれど大宮人の船待ちかねつ

唐崎でなく辛崎であることに注意。

**NAME IS NULL** · 2006/04/10(月) 22:41:07

楽波 -> 楽浪だな

**NAME IS NULL** · 2006/05/11(木) 08:00:17

Times-Tenって導入してるところどれくらいあるんだろう？

**NAME IS NULL** · 2006/05/17(水) 23:35:31

日本じゃ売れてないと思われる

**NAME IS NULL** · 2006/06/06(火) 21:33:03

最近オンメオリデータベースの話をさっぱり聞かなくなったが
ブームは終わったのでしょうか？

**NAME IS NULL** · 2006/06/28(水) 00:19:06

明日(今日）から開催されるDWH&CRMexpo
富士ソフトABC＆高速屋　VS　富士通BSC&ターボデータのオンメモリDB対決が
みれるよ

**NAME IS NULL** · 2006/06/30(金) 00:51:56

不治痛のティンポもオンメモリ化可能だYO

**NAME IS NULL** · 2006/06/30(金) 21:40:54

>>60
ティンポウエアにそんな機能あったっけ？

**NAME IS NULL** · 2006/07/03(月) 01:09:24

オンメモリ可能とオンメモリに最適化されてるのは違うお

**NAME IS NULL** · 2006/07/07(金) 01:45:30

MySQL cluster どうよ？

**NAME IS NULL** · 2006/07/07(金) 23:30:47

>>61
できるな。メモリがジャブジャブあればパフォーマンスは上がる

**保守派** · 2006/07/30(日) 23:41:43

メモリ（ＤＢ）空間活用のポイントは、
・超高速化による、バッチ処理（中間処理）概念の排除、と
・それによる、中間処理結果ファイルの排除（保管量が小さくて済む）
　→（ほとんど）全データをメモリ上に押し込む設計力が必要

この利点を上手く生かせる技術者がどれだけ居るのだろうか？
もちろん、Oracle技術を捨てられない技術者には使いこなせない。

日本の技術者は保守的、日本のＩＴ業界では育たない。
（と思う）。

**NAME IS NULL** · 2006/08/06(日) 22:09:25

Times TenってOracleに吸収されちったのか。
シリコンバレーにいたころ東京エレクトロンの営業さんからえらくプッシュされたのが懐かしい。
こっちは一介の研修生みたいなもんだったし帰国後転職したから忘れてた。

**NAME IS NULL** · 2006/10/19(木) 21:08:19

http://kairos.science-arts.com/index.html

**NAME IS NULL** · 2006/11/20(月) 12:00:08

TimesTen売れているのですか？
Kairosはどうよ？

**NAME IS NULL** · 2006/11/22(水) 11:39:01

TimesTen
http://www.atmarkit.co.jp/news/200607/29/timesten.html
古い記事では、そろそろ新バージョンがでるみたい。

**NAME IS NULL** · 2006/11/23(木) 01:29:02

FastDB
http://www.ispras.ru/~knizhnik/fastdb.html

これはどうなんでしょうね。

**NAME IS NULL** · 2006/11/23(木) 17:34:35

>>70
軽量なメモリＲＤＢＭＳ？？ソースは複雑では無さそうだが ...．？

**NULL is VALID under ODB** · 2006/12/01(金) 10:17:51

>>68
TimesTenはミッションクリティカルな金融系のアプリケーションでは、しっかりシェアを持ってると
お友達の米国人（Stanfordの博士様）が言っておりました。
とても良い製品だけどバカッ高いと。

SQLではないけれど、ODBの生き残りのObjectStoreは、オンメモリーDBです。
実メモリーが沢山あれば、どんどんデータをメモリーにマッピングして、トランザクションも
オンメモリーで行い、その後でトランザクションログファイルに書き込み、そこからさらに
アイドルタイムにDBファイルに転送するという手順で動くため、非常に高速です。
DBサイズの限界は、OSの仮想メモリー空間のサイズにのみ制約されるので、64bitシステムでは
実際上の制限は無いと考えてよいです。
実メモリーサイズを越えるような大きなDBにフルアクセスした場合は、データがページメモリー
にマッピングされていくため、データアクセスでスワップが発生し、スピードが落ちますが
使えなくなる事はありません。
実際に使っていて、最大の特徴はマルチユーザアクセスでのUpdateトランザクションが
非常に高速なところです（当然Readも高速！）。
ロックやトランザクション管理もちゃんとやっていて良いんですけど、問題はSQL無いし
プログラムを全部C++で書かないと駄目なところ。敷居が高すぎて開発者が寄り付かない。

**NAME IS NULL** · 2006/12/01(金) 15:15:47

>>72
> 実際に使っていて、最大の特徴はマルチユーザアクセスでのUpdateトランザクションが
> 非常に高速なところです（当然Readも高速！）。

随分前に使ったことあるけど、マルチユーザで共有しているページを
更新するととんでもなく遅かったぞ。
理由は該当ページを共有してる全ユーザ(MVCC除く)がキャッシュを
破棄するのを待たなきゃいけなかったから。
今は改善されたのか？あのアーキテクチャで改善は無理だと思ったが…
後、トランザクションログのサイズが大きくなると劇的にパフォーマンスが
低下したのも閉口したな。

**NULL is VALID under ODB** · 2006/12/01(金) 21:53:31

>>73
> 随分前に使ったことあるけど、マルチユーザで共有しているページを更新するととんでもなく遅かったぞ。
> 理由は該当ページを共有してる全ユーザ(MVCC除く)がキャッシュを
> 破棄するのを待たなきゃいけなかったから。
> 今は改善されたのか？あのアーキテクチャで改善は無理だと思ったが…
> 後、トランザクションログのサイズが大きくなると劇的にパフォーマンスが
> 低下したのも閉口したな。

それって、プロセス沢山作ってません？
キャッシュはクライアントプロセス毎のリソースなので、マルチスレッドで動かしてやらないと
あちらこちらでキャッシュブレークが発生するのでおそうなりますわな。
後、キャッシュサイズも上手く設定する必要あり。

トランザクションログのサイズは、プロパゲーションのタイミングの調整
で制御できると思います。

今のところ最新バージョンはR6.3で、来年あたりR7が出る予定。
R6の前はR5.1で、R6になるときに大きく変わり、R6.0.4で64bit対応になってます。
R6.0.3以前は、32bitだったので、アドレス空間サイズ4GBの壁があり、キャッシュ
サイズも大きく取れなかったので、キャッシュサイズを超えて、ブレークして
遅くなったりしてた。

**NAME IS NULL** · 2006/12/01(金) 22:57:44

>>74
> それって、プロセス沢山作ってません？

もちろん沢山作ってたよ。サーバが沢山あったからね。

> キャッシュはクライアントプロセス毎のリソースなので、マルチスレッドで動かしてやらないと
> あちらこちらでキャッシュブレークが発生するのでおそうなりますわな。

ってことは基本的なところはたいして変わってないんだな。

> 今のところ最新バージョンはR6.3で、来年あたりR7が出る予定。
> R6の前はR5.1で、R6になるときに大きく変わり、R6.0.4で64bit対応になってます。

俺が使ったのはR4の頃。途中でR5が出たけどバージョンはあげなかったな。

**NAME IS NULL** · 2006/12/02(土) 01:01:02

オンメモリDBを社内LAN全体のMutex代わりに使うのってイケてる？
イケてない場合、皆はどんな方法がベストプラクティスと思ってる？

**NAME IS NULL** · 2006/12/02(土) 10:34:15

そもそも何の排他に使いたいの？

**NAME IS NULL** · 2006/12/02(土) 10:54:21

LANを排他するにはvlan tagを設定するのが簡単だと思う。

**NULL is VALID under ODB** · 2006/12/05(火) 19:26:29

>>75

> 俺が使ったのはR4の頃。途中でR5が出たけどバージョンはあげなかったな。
そうでしたか。R6.0でスレッドごとにトランザクションを処理することが出来るように
なって、SolarisのマルチCPU環境では、スレッド使ってキャッシュをシェアする
トランザクションをパラレルに処理できるようになった。
これで、かなり高速化できてます。

昨日、R6.3が届いたので、これから色々試すところ。

**NAME IS NULL** · 2006/12/20(水) 03:56:50

>>70
FastDB

えーと、マニュアルをちまちま日本語に翻訳したのを
公開してるから探してみて。
ある案件で採用しようと目論んで調べてたんだが
いまいち調べ切れなかった。あと、類似のオンメモリDBとか
オブジェクトDBとか仕事で使ったことないので
比較はよくわかりません。ごめんね。

で、FastDBは

C++でクラスを定義して、マクロをちょっと書き足すと
それがテーブル定義っつーかスキーマになる。なので
データを使う側(プログラム)とスキーマが食い違いにくい。

クラスオブジェクト同士のリンク(1:1、1:N、N:M)
を格納できる仕組みが整ってる。

データ操作はSQLの簡易版みたいなクエリ文を使う。
クエリは事前解釈&パラメータ埋めるだけにもできるポ。
selectの結果は行の集合ではなくオブジェクトの集合。

ロックの範囲が広い。データベース全体をロックのみ。
ロックのオーバヘッドを減らすから、細かくロックする
(なるべく短時間で離す)ように使ってホスィ、とのこと。

あと、1DBに対して複数プロセスがアクセスするとして
1 Writer-N Reader の使い方には強いが、
複数のプロセスが交互に書き込むのは苦手。
レプリケーション（レプリカ造る）のようなモデル
（マイクロソフト風に言うとパブリケーション？）
にはいい。
1プロセスが複数DBを使うのはもちろんOK。
なので、2 Writerにしたいならむしろ2DBで
双方向のレプリケーションにしたほうがいいかもと思った。

マルチスレッドは、posixスレッドかWin32スレッドが使えるが、
作者が作ったラッパー経由でないとだめ。

こんな情報で役に立ったかな？

結構使い方に工夫が要る。まぁでも、オンメモリのDBを使おうと
してる開発ターゲットなら、何を使うにしても工夫は必要だわ。
オンメモリDBを採用しながら
メモリを効率的に使うなどの地道な努力を怠って
スワップメモリまで食うようなプロジェクトでは、
結局のろまなソフトしかつくれないでしょ。
いま隣のプロジェクトがそういう火事になってるよ。

**NAME IS NULL** · 2006/12/20(水) 18:03:42

>>80
ところでレスポンスはどうなんでしょか？（書き込み速度など）

**NAME IS NULL** · 2006/12/20(水) 22:14:56

傍から聞くとO/Rマッピングの組み込みに失敗しましたって読めるのが怖いｗ

**NAME IS NULL** · 2006/12/28(木) 15:47:03

オンメモリーＤＢ、、、なんていらないんじゃない。
オラクルだって、十分速い。
メモリーも安くなったし、、、、

**NAME IS NULL** · 2006/12/29(金) 02:54:00

>>81
聞く前に自分でやってみたの？

**NAME IS NULL** · 2007/01/01(月) 19:32:00

オンメモリDBってExcelのこと？

**NAME IS NULL** · 2007/01/04(木) 14:25:41

販売してたから良く知っている。

**NAME IS NULL** · 2007/04/30(月) 05:52:09

kairosって？

**NAME IS NULL** · 2007/06/23(土) 18:49:01

FSSQLがひっそりと終了したみたいです。
ttp://www.fsi.co.jp/project/k/index.html

**NAME IS NULL** · 2007/07/05(木) 13:03:21

windows でテンポラリファイルを作って、クローズ時に残さない設定にすると
メモリーのみで存在する「ファイル」になる。

.NETのDatasetはデータのメモリ内キャッシュ。

他のソフトとの共有もできるのかどうかは知らないが、目的いかんではオンメモリ
データベースとして使えるのではないか？

**NAME IS NULL** · 2007/07/20(金) 11:43:35

高価という印象が強いのですが、価格は小さい順に
並べるとどうなりますか。

**NAME IS NULL** · 2007/07/21(土) 15:56:31

>>89
確かにそうだけど、DataSetは、テーブルとリレーションでしかなく、
それに対してSQLは実行出来ないから不便なところもあるのでは？

**NAME IS NULL** · 2007/07/25(水) 08:41:24

みて

**NAME IS NULL** · 2007/08/03(金) 16:57:15

＞◆ ターボデータの問題点
＞第五には、製品品質の問題が挙げられます。　
＞ターボデータの商品は、
＞Student Codingと言われるほど製品品質が悪いようです。
　　　↑
　　T●Lさんは、Cで作成したエンジンメーカ(ライブラリ)
　なので、エンジン以外の周辺Prg、製品は
　すべて評価プログラム(サンプル)の位置づけのよう。

　　使い方が難しいので、
　提携組込ベンダー使い方を示すために
　メーカ側が仕方なく用意したものを
　ついでに製品販売しているだけでしょう。
　
　　本来OracleにおけるSQLPlusのように
　ユーザさんに買って使ってもらいたいなら
　お金をかけてメンテすべきと思うが

　「タダのものにはできるだけお金をかけてメンテしたくない」
　日本のベンチャーにはありがちな発想が
　品質の悪さに拍車をかけてしまっているのだと思われる。
　(見せ方が下手で、500倍の処理とか言われている性能も
　ちゃちくみえる)

**NAME IS NULL** · 2007/08/03(金) 22:08:40

現在生き残っているIMDBのリスト作ってくれ

**NAME IS NULL** · 2007/08/07(火) 23:32:26

>>94
1であげたの全部まだ生きて居るんじゃない?

　ターボさん今こんな事遣っているよう
http://www.nextq.jp/com/document.htm
http://www.nextq.jp/com/070609/090609_6-3-1.pdf
http://www.nextq.jp/com/070609/090609_6-3-2.pdf

　あそこ直販してないみたいだから
新機能試せる体験版、何時落とせるんだろうね～
＜あそこのHPのパンフも全然変わってないから
　まだまだ製品化は先なのかも。（苦笑

**NAME IS NULL** · 2007/08/19(日) 15:47:33

Kairos死亡。。。

**NAME IS NULL** · 2007/09/09(日) 02:37:33

>>94
altibaseって新しく出てるよ。
これもメモリデータベースか？？
http://altibase.jp/

**NAME IS NULL** · 2007/09/09(日) 02:41:44

おっ、altibaseはトライアル版ダウンロードできるよ。
使ってみるか。

**ターボWatcher** · 2007/09/28(金) 14:25:14

>>95
いちおうHPに新製品情報でた
体験版はまだ未

**NAME IS NULL** · 2007/10/26(金) 14:00:47

>>20
　ターボデータって
　セック社　とか
いろいろと出資しているところがあるから無理かと思う。

　ところでターボデータって儲かっているの？(ココ上場していない？)

　セック社の決算報告書だと
研究援助投資という名目で
評価損の原因になっているようだが・・・。

**NAME IS NULL** · 2007/11/11(日) 15:46:56

>>99
AktblitzⅡ32の体験版プログラム
http://www.turbo-data.co.jp/j/download/download.html

　この商品価格次第だと思うが
いまいち使えるかどうかは微妙
(つい最近　富士通のOpa1/3も
サーバータイプを
3000万＝＞200-300万に
値下げ発表してたぐらいだし)

**dPCYGxOaFmTOVqHwfQs** · 2007/11/12(月) 11:50:19

2sm6Ey <a href="http://pwjbdfortvsz.com/";>pwjbdfortvsz</a>, [url=http://ogpgvyailina.com/]ogpgvyailina[/url], [link=http://nvhizmubmjir.com/]nvhizmubmjir[/link], http://ozajdbvlouvn.com/

**NAME IS NULL** · 2007/11/15(木) 01:53:26

　そういえば昨日
どのワードかは言わないけど
Wikiにメーカ要望書いた
奇特な方の記載が速攻消されてた。
(書くだけ無駄なのに・・・藁)

　メーカの人間は、まず普通見ないだろうし
見たとしても
自分のとこの製品のいいコメント以外は
消すのがまあ普通だろうしね。
（Wiki自体ステルスマーケティングの温床だから）

**NAME IS NULL** · 2007/11/15(木) 05:30:00

Wikipediaの事をWikiと呼称する
インターねっつ初心者さんでしか？

**ターボWatcher** · 2007/11/15(木) 11:05:07

>>103
　コメント化されてるだけですな。
消されてないだけ良心的なのでは?
＜記載削除されても不思議ではない。

　メモリDBの販売が
大手SI企業経由が殆どの時点で
サポートしたくない(出来ない)からだと。

>>104
確かに初心者っぽい書き方というのは同意。
Wikipediaと書くの遠慮したのか？
一応ググるとWikiでもヒットはしますがね。

**NAME IS NULL** · 2007/12/19(水) 19:19:39

>>13
第五禿同サポート皆無です。
他に買収されないということは技術として意味がないということ
はやくつぶれて欲しいです

**NAME IS NULL** · 2008/01/04(金) 11:14:51

第五、何時2/4(XMLDB?)できるんでしか？
シャーチョサンの本には理論は昔から載ってますデスネ

**NAME IS NULL** · 2008/01/04(金) 16:04:11

　今時Spring+Hibanate全盛期に
SQLやHQLをサポートしてへんDBなんか使いづらいだけでしょうに。

>>106
この記述が確かなら
第五は特にサポートしてくれへんのやろ。
「dll、so以外は全部フリーや！！」
(サポートせーへんで?　とあえて言うてるのかいな)
と連呼している時点で押して図れるのかもしれへんけど

**NAME IS NULL** · 2008/01/05(土) 20:47:05

http://click.j-a-net.jp/1006827/223692/

**NAME IS NULL** · 2008/02/17(日) 12:47:49

TimesTen。東証で採用されたらしく、金融系での引き合いが増えているみたい。

**NAME IS NULL** · 2008/02/17(日) 20:43:40

>>110
さっそくポシャッとるがな
富士通が悪いのか知らんけど

**NAME IS NULL** · 2008/02/17(日) 21:01:14

TimesTenがトラブったの？

**NAME IS NULL** · 2008/02/23(土) 03:33:56

なんでMySQL Clusterがほとんど語られてないん？
まだ実用の段階じゃないって事？
マイナーなDB出されても使う気もおきん。

**NAME IS NULL** · 2008/02/23(土) 04:25:51

>>113
そんな貧乏くさいの興味ない

**NAME IS NULL** · 2008/02/23(土) 21:50:55

>>114

俺はMySQL CLUSTERについて知りたいの（怒）

いいから語れ（怒）

**NAME IS NULL** · 2008/02/24(日) 20:58:12

なんでMySQLスレ行かないの？追い出されたの？

**NAME IS NULL** · 2008/03/12(水) 20:27:21

>>115
[MySQL CLUSTER]って[Oracle RAC]と同じカテゴリやん。＜DBじゃない
ここオンメモリDB板ですが。

**NAME IS NULL** · 2008/03/15(土) 18:42:14

>>117
MySQL CLUSTERはメモリベースだったと思う。
ディスクベースのサポートは比較的最近じゃなかったけな。

**NAME IS NULL** · 2008/03/17(月) 01:04:00

5.1からですよ。

**NAME IS NULL** · 2008/03/17(月) 01:32:53

MySQL CLUSTERの話はMySQLスレ逝け

**NAME IS NULL** · 2008/03/17(月) 12:56:34

MySQL Clusterは事例がない＋エンタープライズ用途
だからoracleとか使うんだろ。MySQLのセミナー行くのが一番いいね

**NAME IS NULL** · 2008/06/18(水) 12:56:33

IBMのsolid 情報ないですかね?

去年の12月位にsolid社の買収のニュースが流れてて
ついこの前、IBMがIMDBだすよ～て発表があったって
程度しか持ちネタがない。

**NAME IS NULL** · 2008/07/01(火) 22:42:43

高速機関５をCRMEXPOでみたよ。ターボーさん発表会行ってきた。　solid　出たよ。 http://www-06.ibm.com/jp/press/2008/06/2401.html　　ネタなし。

**NAME IS NULL** · 2008/07/08(火) 02:09:45

正直ね。SSD32ギガで８発RAID10組んで、
16ギガくらいメモリ積めばオンメモリDBって
要らないと思うんだけど、
この構成で何か問題ある？

**NAME IS NULL** · 2008/07/08(火) 05:38:21

本気でやろうとしてるならまだしも、単なる妄想で言われてもねぇ

**NAME IS NULL** · 2008/07/08(火) 09:37:59

今のIMDBって、高速なレスポンスを安定して得る事が重要な
証券システムとか、ちょっと特殊な用途にしか割に合わないと
思うんだけど、どうでしょう?

もう少しIMDB本体の価格が安ければ、
安っいサーバーにメモリを大量にのせて
数倍程度だけど安定して速くなりますよ～
スケールアウトも安くすみますよ～
って使い方が考えられるんだけどなぁ

HWｱﾌﾟﾗｲｱﾝｽ系の高価なDBとの住み分けという観点から
IMDBは、まずはｷｬｯｼｭ的な扱いとし
容易に安価に大量導入できるといった
路線を目指して欲しいと思うなぁ。

**NAME IS NULL** · 2008/07/08(火) 10:46:09

そういうので置き換えられるのもあると思うけど、
普通のSSDだとSATA,SASで繋ぐんだろうから、直接アクセスできるメモリと比べたら、
帯域もレイテンシも比べものにならないでしょう

**NAME IS NULL** · 2008/09/22(月) 23:54:59

こういうのの草分け的な案件ってどういう雰囲気なんだろうな
東証のニュースとか若干心が躍ったぜ、正直な話
まさにシステム開発界のF1

**NAME IS NULL** · 2008/11/23(日) 01:52:57

いや、既にコンビニの店舗売上データ集計バッチとかで使われてるから…

**NAME IS NULL** · 2009/08/02(日) 08:28:54

オンメモリでも最終的にはコミットした分をディスクに残せないと困りますよね？
その辺どうなってんの？
別のマシンにネットで飛ばすとか？

**NAME IS NULL** · 2009/08/02(日) 13:52:36

>>130
バックエンドにOracleやDB2など普通のDBMSを使うことが多いはず
つまりIMDBはキャッシュ

**NAME IS NULL** · 2009/08/03(月) 21:31:53

なるほど、巨大なキャッシュがあって、write throughになってると思えばいいんでしょうか。
ということは、書き込みの多い場合にはそれほどパフォーマンスの向上はないんでしょうか？
上でも東証に使われてるという話がありますが、writeはかなり頻繁に起こりますよね？
比率の問題なのかな。

**NAME IS NULL** · 2009/08/03(月) 22:54:30

>>132
ライトスルーだけじゃなくライトバックも選べる

**NAME IS NULL** · 2009/08/07(金) 08:01:07

>>130
別ＤＢを利用しないものだと、別ノードにバックアップする製品もある。
あと、SANに保存したり。

**NAME IS NULL** · 2009/08/07(金) 08:03:21

>>132
キャッシュとしてじゃなくて、まんまＤＢとして運用出来るよ。

**NAME IS NULL** · 2009/08/07(金) 09:04:46

できるけどしないだろ、この値段出す案件では

**NAME IS NULL** · 2009/08/07(金) 09:59:10

132です。
色々ありがとうございます。
一番不思議に思っているのが、
証券取引のように大量かつ高いリアルタイム性が求められる環境で
オンメモリデータベースはどうやっていわゆるACIDというんでしょうか、
一貫性とか永続性を確保しているんだろうと不思議なんです。
オンメモリデータベースの最大のウリ(ですよね？)である速度パフォーマンスを
維持したまま。
ロストできないものはディスクにコミットしないと応答できないとすれば
結局同じじゃないのかなと。
株取引で、リアルタイムで返した結果をあとで取消なんてできないですよね。

**NAME IS NULL** · 2009/08/07(金) 10:14:43

>>137
複数の選択肢があって当然トレードオフがある
スタンドアロンで使う場合はディスクにトランザクションログを保存したり
キャッシュとして使う場合はバックエンドのDBとの間で実質
2フェーズコミットしたり(バックエンドのDBは2PCだとは知らないが)

**NAME IS NULL** · 2009/08/07(金) 10:29:16

>>137
> 株取引で、リアルタイムで返した結果をあとで取消なんてできないですよね。

株で応答速度が要求されるのは時価を扱うところだがそういうところは
ぶっちゃけオンメモリだけで済むことが多い
プログラミングトレードなんかが典型だが入ってくる時価を
トランザクションログを用いて更新する必要はない
オンメモリだけで保持しておk
発注する情報は信頼性の高いDBに保存するがそこは
そこまでの応答速度は要求されない
(注文を市場に出すまでの速度は重要だが)
まぁこの領域はIMDBよりCEP(DSMS)だな

**NAME IS NULL** · 2009/08/07(金) 22:29:29

>>137
そういうのは用件を整理して、高速読みだしが必要なものは、ジャーナル使わないとか
いろいろと工夫します。

**NAME IS NULL** · 2010/02/13(土) 21:46:09

誰か聞いてくれよ
今開発している案件のＤＢが、MySQL-inodbからMySQL Cluster-ndbclusterにストレージエンジンが変更になったんだよ。
俺の構想では、MySQL-inodbをレプリケーションしてスレーブ作って、負荷分散させようと考えてたんだよ。

そしたら１次請の会社のＳＥが、MySQL Clusterを使うって方針に決まったから、MySQL Clusterについて調べろっていうんだよ。
自社でテスト環境作ってたら、データノードのプロセスが突然落ちる＞そしてデータノードのプロセスが起動しなくなってＤＢをcreateしなおして、レストアしないといけないのよ。
後は、configのパラメータの中身が意味不明。開発者向けのスイッチかと思われるほどの無残さ。
joinが遅いとか、configを帰ると３時間ものローリングリスタート。時々落ちるおまけつき。
deleteで消した行の領域は、リスタートしないと開放されないとか…。

俺の感想だと糞ＤＢ。バグだらけ
これほんとに運用されているシステムで使われているのか？

誰か使ってるやついたらなんか教えてくれ？

**NAME IS NULL** · 2010/06/02(水) 21:32:04

誰もいない・・・

>>141
まだ生きてるか？
聞くだけきいたぞ。

**NAME IS NULL** · 2010/06/07(月) 06:09:01

オープンソースの分散インメモリデータベース「VoltDB」が登場しました。

VoltDB community
http://community.voltdb.com/
「NoSQL」を上回る性能を目指す次世代型高速SQLデータベース「VoltDB」登場
http://sourceforge.jp/magazine/10/05/27/033236
VoltDB登場 ? RDBMSのようでRDBMSではない新システム
http://www.nonsensecorner.com/wp25/?p=4297
NoSQLを超えるSQLデータベース「VoltDB」。Cassandraとベンチマーク対決！
http://www.publickey1.jp/blog/10/nosqlsqlvoltdbcassnadra.html
VoltDB は何故早いのかは問題ではない。何をするためのシステムなのかが問題だ
http://www.nonsensecorner.com/wp25/?p=4299
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
http://www.publickey1.jp/blog/10/nosqlvoltdb.html

**NAME IS NULL** · 2010/12/23(木) 00:50:48

インメモリDBって今市販の２ソケの鯖だと
何QPSぐらい出るの？

**NAME IS NULL** · 2011/07/28(木) 15:19:11.85

インメモリＤＢって単なるツリーとハッシュだろ？
SQLじゃなくてAPIで操作したい

**NAME IS NULL** · 2012/02/09(木) 18:33:34.26

>>124
最近、そういう構成も現実的に
なってきたなあ。

ioDriveだっけ？とかどうよ？

**NAME IS NULL** · 2012/02/12(日) 12:41:17.28

インメモリってそもそもソフトウェアの構成がメモリにデータがある事を基準に最適化されてるから、
SSDに普通のRDBMS乗っけるより1000倍速いって話じゃなかったっけ？

**NAME IS NULL** · 2012/02/12(日) 13:06:54.43

I/Oなんて間に入れたら遅くてしょうがないだろ
1000倍は知らないが。

**NAME IS NULL** · 2012/02/15(水) 18:10:42.79

>>147
SATAとかのドライブインターフェイスが
ボトルネック。
PCIとかで直付けすればまだまだ全然
速くなる。

**NAME IS NULL** · 2012/02/15(水) 18:43:14.04

>>149
そもそもOSのIOが遅い訳で。
直接メモリにアクセスするからメモリDBの速さが生きるんでしょ？

**NAME IS NULL** · 2012/02/16(木) 13:14:42.30

>>150
大した遅さじゃないだろ。
OSの処理なんか、HDDの物理動作に
比べたら、かかる時間は誤差みたいな
もの。

つか、SSD直付け構成はすでに
製品化されてる。
全然速いらしいぞ。

**NAME IS NULL** · 2012/02/16(木) 19:23:42.93

>>151
そりゃHDDに比べたら速いけどさ。

メモリアクセスよりはかなり遅いと思うよ。

**NAME IS NULL** · 2012/03/20(火) 15:41:16.63

>>152
いや、そうでもない。
比較すると遅いだろうが、総合的には充分以上にもなるんだろう。

ttp://www.publickey1.jp/blog/12/fusion-ioceo.html

?PLT(12081) · 2013/12/15(日) 22:52:17.45

RDBって何の略？

**NAME IS NULL** · 2015/06/27(土) 23:41:56.19

た
http://i.imgur.com/Y60C57J.jpg

**NAME IS NULL** · 2015/08/17(月) 21:43:36.19

準決勝と決勝は　西日本の大学卒の公平な審判だけで運営してください
早稲パイアは要りません　

**NAME IS NULL** · 2015/09/10(木) 16:32:05.28

CQLについて調べてるんだけどここでいいのかな？

**NAME IS NULL** · 2015/11/16(月) 12:31:20.58

　　　　　　　　　　　　　　　　　　　【重大】

　　　　　　　放射能テロ虐殺犯の安倍が、核兵器を密造か！？

三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある　書けばツイッターで速攻削除されている
https://twitter.com/toka iamada/status/664017453324726272

安倍晋三の兄が関与している三菱重工　核開発疑惑についていくつかツイートしたが、反応がないから変だと思って、自分のタイムラインを調べてみたら、
完全に削除されていた　私のツイートで、安倍政権に都合の悪い情報は速攻削除されているこれは驚いた　ここまでやるのか
https://twitter.com/toka iamada/status/664016524592574464

先ほど、まだ数分以内に、三菱重工の核開発疑惑について、いくつかツイートしたが、検索しても出てこない　多くの人のタイムラインに出てこないツイート直後に消されてしまったようだ
https://twitter.com/toka iamada/status/664015521830952960

　　　　　　　　　　　　　　　　　　　【警告】

　　　　　　　　　　死亡者数、戦時なみの勢いで増加中！！

川崎病の年間患者数、史上最高に　1万5千人を突破、ピーク時を超える　最初の報告は水爆実験後。本当の原因は被曝
震災以降に死亡者数が、第二次大戦に匹敵するほど急増している
厚生労働省によると平成２３年から平成２５年の累計死亡者数は３６０万人以上に急増。今の日本は太平洋戦争時の時と同じくらいの勢いで人が亡くなっている
除染袋回収の作業員５人疲労で動けず、自衛隊など救助　　疲労じゃないだろう、被曝障害だろうよ　死んだように眠る人々（写真多数）
http://s.ameblo.jp/kaito000777/entry-12031605335.html

【川島なお美の食べて応援が恐怖すぎる】自宅でも進んで食べて応援
1年後・軽くぶつけただけで肋骨骨折　2年後・眼球から出血は半年に一度　3年後・胆管に腫瘍、血液検査は異状無し　4年後・逝去夫は片目失明、愛犬もがん
https://twitter.com/2ch_NPP_info/status/648256313571479552

・・・今も、原子力緊急事態宣言中… 対策本部長は安倍首相。

**NAME IS NULL** · 2015/11/16(月) 21:05:33.00

暇人におすすめのゲーム
http://goo.gl/dlkwgT
20000円貰えるよ

**NAME IS NULL** · 2016/07/31(日) 21:46:54.69

>>1
バッファキャッシュが大きいとあまり差はないけどな。

**NAME IS NULL** · 2017/02/02(木) 09:02:42.27

Prologで十分。

**NAME IS NULL** · 2017/12/29(金) 12:03:07.15

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

JWZ1ULE8TV

**NAME IS NULL** · 2018/02/15(木) 00:39:00.38

☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

**NAME IS NULL** · 2023/09/27(水) 15:22:43.99

おおきに、やめて

**NAME IS NULL** · 2024/04/14(日) 02:06:58.92

メモリ上だと速いだろうというよくわかっていない人間が騙されているだけ