jwcolby
jwcolby at colbyconsulting.com
Mon Jul 4 11:13:11 CDT 2011
Jim / Gustav,
In any case it seems like a forced fit if it fits at all.
I read the blogs and they are talking about responding to millions of reads / writes of massive
quantities of text by massive quantities of users, using tens of thousands of machines to distribute
the load. Look at the users and who are they? Search engines and social network sites.
From the web site that Gustav posted:
MongoDB?
“MongoDB (from "humongous") is a scalable, high-performance, open source, schema-free,
document-oriented database.”
I don't see how this describes me in any way.
http://www.michaelckennedy.net/blog/2010/04/22/TheNoSQLMovementLINQAndMongoDBOhMy.aspx
to quote:
"This move towards NoSQL is driven by pressure from two angles in the web application world:
* Ease-of-use and deployment
* Performance - especially when there are many writers as compared to the number of readers
(think Twitter or Facebook)."
I don't see how this describes me in any way.
I am not opposed to using this, however I have to see that it somehow fits and I don't see that.
1) I don't have tens of thousands of machines to distribute the load. And never will!
2) I don't have tens of thousands of users trying to simultaneously read / write to the data store.
And never will!
3) I am not storing large quantities of text (think blog text, web page text, pictures etc) per read
/ write. And never will!
4) I don't have, nor do I wish to maintain a bunch of old / new PCs as a huge network. These guys
(Google etc) build entire data centers with highly replicable computers, but they do so for
scalability and replicability (redundancy). They also have a megawatt power line coming in to their
data center. They also spend a couple of hundred million building the data center. They also have
hundreds or thousands of programmers writing their code. How does any of that sound like me?
5) I have spent a year building a pretty sophisticated system for taking data in SQL Server, huge
quantities of records, and getting them exported out of the data store into CSVs, through a VM /
third party software, and then back in to the server (updating thousands of addresses when people
move). I have custom software to build orders and get selected sets of name / address records out
to fixed width files. The selection process depends entirely on where clauses - where age in
('1','2','3') and Income in ('a','b','c') and MOB = 'Y' and...
This is SQL stuff. It requires an easily manipulatable SQL language. When something doesn't work I
need to have an environment that I can cut and paste my sql statements and troubleshoot them. My
data has never touched a web page. In fact 99.9999999% of my data has never even been seen by human
eyes, other than when it was originally entered by each person typing their name / address into a
web site sime time in the last 10 years.
*None of that* sounds like these systems (to me). These systems are designed precisely to take
pages of data typed in by millions of users and store them in an efficient manner, then pull the
entire thing back out millions of times to display on a web browser.
Jim, I think these systems are the cat's meow for the purpose they are intended for, but my data and
the way I use my data is just not that paradigm.
In the meantime I have already built a hardware / software system that does what I want, and I did
it on a budget that is remarkably small. Long term I spend around 2% of my income on hardware.
Perhaps even 1%. And I did it with myself and a 3 hour / day part time programmer. I really don't
get that throwing all that away to start over with a database designed to fit Google's / Facebook's
needs is a good thing to do. To be honest, if I were starting from scratch, I don't think it would
be the right tool.
The fact that it is a million times faster at what it does doesn't matter if what it does isn't what
I do.
John W. Colby
www.ColbyConsulting.com
On 7/4/2011 5:50 AM, Gustav Brock wrote:
> Hi Jim
>
> But Casandra doesn't seem to be much .Net/C# friendly. Clients exist only for the old version 0.7, and both of these seem to provide nothing that come close to DataTableAdapters or the like (not to mention LINQ), only simple command-type access:
>
> http://aquiles.codeplex.com/
>
> On the other hand, MongoDB seems to have proceeded further with NoRM:
>
> http://iridescence.no/post/NoSQL-Getting-started-with-MongoDB-and-NoRM.aspx
>
> /gustav
>
>
>>>> accessd at shaw.ca 04-07-2011 05:10>>>
> Inline:
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Sunday, July 03, 2011 2:41 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] SSD, The Game Changer - SQL Man of Mystery -
> SQLServerCentral.com
>
> Jim,
>
> I read the first article and I don't see how it fits at all.
>
> * It fits very well. First in overview this database does not require a
> single PC to run the database. It is distributive in nature so you can just
> add nodes to a bunch of old new and old PCs. The main problem with the
> database as you have it now is that it is dependant on the hardware of a
> single box. Just like in 2006 the single CPU reached it maximum and
> multi-core processors were then created. Cassandra runs like a multi-core
> PC. When the database is running on numerous PCs it is like running a full
> RAID.