Cloud computing: scalable DB

[Ruslan Zasukhin]

On 18/5/10 4:04 PM, "David Bovill" <david at vaudevillecourt.tv> wrote:

Hi All,

* I wonder if anybody from you going to setup your own 1000 computer-servers
cluster(s)?  Like this must do Google and Amazon

If not - then excuse me, guys you have completely different tasks than
google.
 

* Andrea Garcia points few key-value dbs. Okay, I have jump to Riak,
Have overview its API, have try to read about Query Language ...

<https://wiki.basho.com/display/RIAK/Loading+Data+and+Running+MapReduce+Quer
ies>

And it not looks for me clear ... Easy for development ...
Even near easy as SQL ...


* If somebody DREAMs about API-level access to db data without SQL, welcome
to Valentina DB, which provides not only SQL, but **very reach** API to work
with data on low level actually, about 1000 methods in 40-50 classes.


> I particularly like the idea of not having to get into complex relational db
> design, but using simple parallel tables and doing the joins in the
> application layer ( ie revTalk) - seems the way to go to me - if you can
> break the data into object-like chinks where your parallel queries retrieve
> small quantities of data that you use revTalk to massage - sounds great. Not
> for banks maybe - but for most of the rest of use cases.

* As for me this sounds like usage of API Level ... But it is NOT always
great as you may think.

You really want write in your app layer joins???
In hundreds of places?

Or you will write it once? But then sense? You will just invent a bike which
exists for years in SQL engines... And I thin mature SQL engines will do
this job much better than you will be ... Than more in not super-fast REV
layer.

So for me personally this wow-Key-value-clouds  thread sounds somehow
strange :-)

Once again, that tools are only and only for companies which really
establish incredible by count computer clusters... Do you?


** But if you do not like Relational model, if you do not like SQL,
Again, Welcome to Valentina DB, which provide

  * Relational model
  * Object Relational model
  * Navigational model (remember dbVista?)

And all these models can be used in both SQL and pure API way.

P.S. We - recommend to use API way, mainly for development of apps which
work with local dbs. Then you MAY see speed ups comparing to SQL, because
you CAN do hard-coding of algs in your app layer code because YOU KNOW some
special things about your app.


> Thanks Andre:
> 
> On 18 May 2010 13:18, Andre Garzia <andre at andregarzia.com> wrote:
> 
>> 
>> * CouchDB http://couchdb.apache.org/
>> * MongoDB http://www.mongodb.org/ (there's a mongo db hosting service at
>> MongoHQ )
>> * Cassandra http://cassandra.apache.org/
>> * Riak http://riak.basho.com/
>> 
> 
> I think it is only really Amazon SimpleDB and Google App engine that offer
> automatic cloud-based scaleability? Perhaps MongoDB - but I like the idea of
> going with a big player on this.
> 
> At the moment it seems that SimpleDB is offered optimally in different
> regions, and I am not quite sure yet how you would offer global access based
> on a single data source offered in all regions (with SimpleDB the regional
> instances are seperate stores) - maybe AppEngine??? For now I think unless
> you want to write in Python code as well it is better to use SimpleDB from
> Rev - that way you can access it from Desktop as well as webApps.
> 
> Also interesting though more expensive is the idea of using MySQL (sqlLite
> locally) and being able to move over to Amazon
> RDS<http://aws.amazon.com/running_databases/#rds>for scalability - but
> you only need that for complex DB's I think.
> 
> This is a really good read and recent review at
> InfoWorld<http://www.infoworld.com/d/data-management/slacker-databases-break-a
> ll-the-old-rules-599?page=0,7>
> .
> 
> I think most of the data we're trying to store these days is document based
>> where we have something abstract which we call a document and this document
>> have properties and fields where we store data or other documents such as
>> an
>> address book can have different entries and fields for different contacts.
>> This kind of "problem" is easily solved with the above solutions and harder
>> to code with plain old relational systems.
>> 
> 
> I particularly like the idea of not having to get into complex relational db
> design, but using simple parallel tables and doing the joins in the
> application layer ( ie revTalk) - seems the way to go to me - if you can
> break the data into object-like chinks where your parallel queries retrieve
> small quantities of data that you use revTalk to massage - sounds great. Not
> for banks maybe - but for most of the rest of use cases.

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]