Matt, Your skepticism is healthy, and I would agree that most systems tend to ossify after 30 years. With Caché/GT.M/Globals, the developers definitely ossified, but the systems have adapted to new capabilities quite well. You did point out one of the things Cache/GT.M have that I omitted, ACID transaction processing. Since both are used extensively in large financial institutions, I tend to forget that since it is so basic to the environment.
I don't know that I could point to a specific challenge that they have 'risen to' that Mongo, CouchDB et al haven't or can't rise to also. You ask why use Cache/GT.M instead of Mongo, CouchDB? I tend to ask it the other way, why use Mongo, CouchDB, or any other 'new' system if it doesn't offer anything that Cache/GT.M does? Maybe it's because I'm older now, and instead of mistrusting anyone over 30, I now doubt anyone under 30? :-) Also, don't think of Cache/GT.M/Globals as just a key/value pair database. They are really multi-key/value databases, and until you've used it, the difference is difficult to appreciate. Joins really aren't necessary, the data is (for the most part, it is possible to do it wrong) naturally related. I think it is difficult for most traditional IT folks to wrap their mind around it, because from the beginning it was targeted at a different use case than other databases. The technology was originally developed at a health care institution to handle health care data, as opposed to financial data that almost all systems were being developed for. Financial data tends to be modeled on nice neat tables made up columns of numbers, with an occasional string thrown in. A lot of attention is paid to CPU and sequential access performance since that data is typically used for large aggregations and analysis. Healthcare data is messy, lots of strings/text with very few numbers, inconsistent actions for the same activities, poorly defined workflows, etc. Sequential access to healthcare data is not terribly valuable, but very fast access to any particular piece of data is. Say when a patient shows up in the ER, and you need to see his/her records from their last visit 5 years ago. So the technology behind Caché/GT.M are optimized for random access to string/textual data of inconsistent structure. The database was designed to optimize what was then (and still is) the slowest part of any computer system, the data storage system. That doesn't mean CPU cycles were wantonly wasted, but it wasn't the highest priority item. This is too long and too 'preachy', but I hope I helped you understand it better. Sometimes my passion for the technology gets in the way..... Mark -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
