mongodbを試した。メモ―である。
・mongod.exe
＝＝＞サーバーデーモン
・mongo.exe
＝＝＞クライアント
・client command
db
show dbs
use sample
db.sample_coll.insert({"key1":"value1","key2":"value2"})
=>MongoDBで基本的なドキュメントの操作する場合は、操作対象のデータベースとコレクションを指定する必要があります。
db.sample_coll.find()
＝＞insert()と同様に、データベースとコレクションを指定する必要があります
db.sample_coll.find({"key1":"value1"})
db.sample_coll.findone({"key1":"value1"})
db.sample_coll.find({"key1":{$ne:"value2"}})
=>条件検索、ne(not equal) gt,gte,in,lt,lte,ninなどがある。
db.sample_coll.find( {$where:""})
db.sample_coll.update({ "_id" : ObjectId("51068b04b796a688e5d541a9")}, {$set : { "key1" : "value100", "key2" : "value200" }},false,true)
=>update
db.Orders.ensureIndex({Name:1});
＝＞インデックスをつける
■関心事
・Concurrencyはどうなる？
MongoDB allows multiple clients to read and write a single corpus of data using a locking system to ensure that all clients receive the same view of the data
and to prevent multiple applications from modifying the exact same pieces of data at the same time.
＝＝＞ロックがあるね。って。うわさの高並列度はどこから？？？
Locks help guarantee that all writes to a single document occur either in full or not at all.
＝＝＞もしかして粒度はちっちゃいのこと？
MongoDB uses a readers-writer [1] lock that allows concurrent reads access to a database but gives exclusive access to a single write operation
＝＝＝＞ここはどうでも改善できないね
・他のメリット
・複数なDBサーバーが並んで、そいうcluster、分散かな。。
・来た。。Key-Valueの構造により、オブジェクトの特定が高速化される
＝＝＞データ構造上で、大量なデータ処理に適しているのことね。mapreduceで分散並列処理など
・じゃ、hadoopは
＝＞Apache Hadoopは大規模データの分散処理を支えるJavaソフトウェアフレームワークであり、フリーソフトウェアとして配布されている
＝＝＝＞middleWareだね。
■■■Spring Data
目指すところは端的に言うと、Springのプログラミングモデルをベースとして、
このようなさまざまなデータストアに対しインターフェースの抽象化と共通化を提供することです。
SpringのプログラミングモデルとはDIやAOP、それにPOJOを利用したデータアクセスです。
実際にはSpring Dataプロジェクトはさらにサブプロジェクトとしてサポートするデータベースに応じて開発・提供が行われています
ある会社の求人：
言語: Scala, Java, Objective-C, C++, Python, Ruby, JavaScript など
ミドルウェア・フレームワーク: Cocos2d-x, Unity, Play framework, Lift など
DB: MySQL, MongoDB, Cassandra？？なにこれは？, Memcached など
管理: Git, Redmine, Capistrano, Chef など dumbo???????
■It turns out that MongoDB is immediately attractive, not because of its scaling strategy,
but rather because of its intuitive data model. Given that a document-based data
model can represent rich, hierarchical data structures, it’s often possible to do without
the complicated multi-table joins imposed by relational databases. For example,
suppose you’re modeling products for an e-commerce site. With a fully normalized
relational data model, the information for any one product might be divided among
dozens of tables. If you want to get a product representation from the database shell,
we’ll need to write a complicated SQL query full of joins. As a consequence, most
developers will need to rely on a secondary piece of software to assemble the data into
something meaningful.
＝ー＞直感的なデータモデル
most developers now work with objectoriented
languages, and they want a data store that better maps to objects
==>わかり安いので、開発効率がいい？