Oracle Big Data Appliance...an E10K for 2012?

Seems like a packaging play than product....Box was turn off on floor, no UI demo

Click to read more ...

Exalytics and NoSQL

W, HW and more HW....Exalytics is a new box Oracle announced today that stuffs a lot of spindles and 1TB of memory plus a new version of Essbase into a box

Click to read more ...

Oracle and NoSQL - Sleepycat wakes up? [updated]

Oracle has been hinting at taking BerkelyDB aka Sleepycat into the NoSQL world for quite a few months.

Is Berkeley DB a NoSQL solution?

Using Oracle Berkeley DB as a NoSQL Data Store

Today they made a formal announcement...along with many others. Not a lot has changed so far - just the name.

Here is what I know:

- Still a key-value data-store. 

- Major key has quite a lot of primacy - see MongoDB for constraints.

- Not shared nothing but has some HA capabilities.

- Xquery as standard interface (now MarkLogic isn't alone!)

Click to read more ...

NoSQL + Developer Skill Sets

One of the thrusts of the discussions at NoSQLNow! conference have been the benefits of parallelism.  The benefits of horizontal scale out accrue because the tasks can be paralleled - either horizontal partitioning or pipelining.

However, dividing up those tasks into parallel structures is a fairly complex/expensive activity on the development side.  Whether it's deciding on shard-points in MySQL or writting map functions for Hadoop, the application of parallism to many tasks requires thought work that is atypical from previous IT work and possibly divergent to many of the other skills needed from corporate developers.

This seems most accute at the data cleansing work in new warehouses - understanding root causes and abstractions needed to build good data for analysts and understanding how to manage the workload seems fairly divergent right now.

Old SQL vs. NewSQL - Stonebraker August 24th, 2011

Great talk from Mike Stonebraker pitching VoltDB/NewSQL...

- Legacy DMBS code lines are too old, too slow, should be sent to the rest home for old software.

- SQL isn't the problem - SQL very efficient.  Overhead of DBMS's make them slow.

- Latching, Recovery, Buffer Pools and Logs each take up apx. 24% of resources, 4% of resources into real work (joining, computing.)

- If you know you'll never, ever need ACID, then go ahead with something else...but don't try to move back, you'll fail.

Briefing afterwards with an engineer:

- Everything is a stored procedure (stored procedure in SQL = functional....)

- Distributed heart-beat - everything gets a sequence #, no TP monitor - SP's are executed in sequence when it knows the current # is ahead of it's backlog...so eventually concurrent but not simultaneously concurrent (I think...)

- All replicas are masters (sort of the opposite of horizontally scalable)

- 2GB footprint, single threaded, no shared memory

- Open Source