OLTP
Analysis of database management systems designed with a focus on OTLP (OnLine Transaction Processing) uses.
EnterpriseDB has a huge partisan in FTD
The Register has a rip-roaring story on a (currently partial) conversion from Oracle to EnterpriseDB. Basically, FTD is royally pissed-off at Oracle, and EnterpriseDB stepped in with a very fast conversion.
Apparently, FTD decided they needed to Do Something after a Valentine’s Day meltdown, and the project was completed on EnterpriseDB in time for Mother’s Day.
One note of caution: When a user supports a vendor’s marketing this emphatically, it usually has gotten nice breaks on price and/or service. Your mileage may vary. On the other hand, EnterpriseDB is still a small enough company that, if you want them to love you to death, you can be pretty well assured that you’re important enough to them that they’ll do so.
Keep getting great research about data management and related technologies. Get a FREE subscription by RSS/Atom or e-mail!
Categories: Emulation, transparency, portability, EnterpriseDB and Postgres Plus, Mid-range, OLTP, Oracle | 2 Comments |
Webinar Wednesday June 27 at 2:00 pm ET
I’m sorry for the short notice, but — well, never mind what the distractions have been. This Wednesday, at 2:00 pm Eastern time, I’m doing a webinar on behalf of Solid. The core subject is memory-centric OLTP data management. I will of course also cover some DBMS and memory-centric generalities.
More info and sign-up can be found here.
Categories: In-memory DBMS, Memory-centric data management, OLTP, solidDB | Leave a Comment |
Memory-centric vs. conventional DBMS — a Solid difference
I had the chance to talk at length with Solid Information Technology tech guru Antoni Wolski about their memory-centric DBMS technology architecture. The most urgent topic was what made in-memory database managers inherently faster than disk-based ones that happened to have all the data in cache. But we didn’t really separate that subject from the general topic of how they made their memory-centric technology run fast, from its introduction in 2002 through substantial upgrades in the most recent release.
There were 4 main subtopics to the call:
1. Indexing structures that are very different from those of disk-based DBMS.
2. Optimizations to those indexing structures.
3. Optimizations to logging and checkpointing.
4. Miscellaneous architectural issues.
Read more
Categories: In-memory DBMS, Memory-centric data management, OLTP, solidDB | 4 Comments |
SolidDB caching for DB2
It’s just at the proof-of-concept stage, but Solid has a nice write-up about SolidDB being used as a front-end cache for DB2. Well, it’s a marketing document, so of course there’s a lot of pabulum too, but interspersed there’s some real meat as well. Highlights include 40X throughput improvement and 1 millisecond average response time (something that clearly can’t be achieved with disk-centric technology alone).
Analogies to Oracle/TimesTen are probably not coincidental; this is exactly the upside scenario for the TimesTen acquisition, as well as being TimesTen’s biggest growth area towards the end of its stint as an independent company.
Categories: Cache, IBM and DB2, Memory-centric data management, OLTP, Oracle, Oracle TimesTen, solidDB | 1 Comment |
Thoughts on database management in role-playing games
I’ve just started a research project on the IT-like technology of games and virtual worlds, especially MMORPGs. My three recent posts on Guild Wars attracted considerable attention in GW’s community, and elicited some interesting commentary, especially for the revelation of Guild Wars’ very simple database architecture. Specifically, pretty much all character information is banged into a BLOB or two, and stored as a string of tokens, with little of the record-level detail one might expect. By way of contrast, Everquest is run on Oracle (and being transitioned to EnterpriseDB), at least one console-based game maker uses StreamBase, and so on.
Much of the attention has focused on the implications for the in-game economy – how can players buy and sell to their hearts’ content if there’s no transactional back-end. Frankly, I think that’s the least of the issues. For one thing, without a nice forms-based UI you probably won’t create enough transactions to matter, and integrating that into the game client isn’t trivial. For another, virtual items can be literally created and destroyed by the computer, with no negative effect on game play, a factor which drastically reduces the integrity burdens the game otherwise would face.
Rather, where I think the Guild Wars developers at ArenaNet may be greatly missing out is in the areas of business intelligence, data mining, and associated game control. Here are some examples of analyses they surely would find it helpful to do. Read more
Categories: Application areas, Games and virtual worlds, Memory-centric data management, OLTP | Leave a Comment |
DBMS plug-compatibility gaining steam
ANTs Software’s primary focus isn’t really even on DBMS any more. Even so, it just announced a deal to replace Informix in a large retail chain’s in-store systems. (In its 1990s heyday, Informix wound up running in-store systems at an impressive list of major retailers. Of course, Informix was long ago acquired by IBM.)
EnterpriseDB has probably passed ANTs in the DBMS plug-compability business. And taken together they’re still pretty small. Even so, plug-compatible DBMS replacement has to be taken seriously as a (possibly) emerging trend. Economically, it makes all the sense in the world.
Categories: ANTs Software, Emulation, transparency, portability, EnterpriseDB and Postgres Plus, IBM and DB2, OLTP | Leave a Comment |
The database technology of Guild Wars
I have the enviable task of researching online game and virtual world technology. My first interview, quite naturally, was with the lead developers of a game I actually play – Guild Wars. The overview is in another post; that may provide context for this one, which focuses on the database technology. (I also did a short post just on the implications for Guild Wars players.) It also has a brief description of what Guild Wars is – namely, a MMORPG (Massively MultiPlayer Role-Playing Game) with the unusual feature that most of the game world is instanced rather than utterly shared.
First, some scope. ArenaNet (Guild Wars’ developer, now a subsidiary of NCsoft) runs Microsoft SQL Server, mainly Enterprise Edition, having just switched to 2005 4 months ago. They run 1500-2500 transactions/second all day, spiking up to 5000 in their busiest periods. They have no full-time DBA, and when the developers started this project they didn’t know SQL. They’ve only had one major SQL Server failure in the 2+ years the game has been running, and that was (like most of their bugs) a network driver problem more than an issue with the core system.
As for what’s going on — there are a few different kinds of database things that happen in an instanced MMORPG. Read more
The FileMaker story
Unfortunately, the first draft of this post got eaten. I’m now trying again.
In response to its small but vocal constituency, I got myself briefed on the FileMaker story. My conclusion, in a nutshell, is that FileMaker sometimes is a good alternative to low-end use of a standard relational DBMS. If you do feel able to use more standard-style products, you often should, for all sorts of obvious flexibility and future-proofing reasons. But if you can’t, or if you’re really confident the project won’t grow past a certain level, the FileMaker class of products can be a very appealing alternative.
Make no mistake; FileMaker is very different from conventional DBMS/app dev tool combos (and that’s the right comparison, as it combines aspects of both product categories into one). Read more
Categories: FileMaker, OLTP | 14 Comments |
Whether or not to use MySQL
CIO Magazine has a pretty superficial back-and-forth about whether or not to use MySQL in enterprises. For example, one of the strongest claims in the pro-MySQL article is the not-so-staggering observation (italics theirs)
One way MySQL achieves this scalability is through a popular feature called stored procedures, mini, precompiled routines that reside outside of the application.
And the anti-MySQL article doesn’t have much in the way of crunchiness except for the fairly well-reasoned
Most of the required features for an RDBMS are firmly in place with the release of MySQL 5.0, but we can legitimately consider the maturity of some of these features as a possible reason to shy away from MySQL. For example, the lack of views, triggers and stored procedures has historically been the major criticism of MySQL. These have all been supported by MySQL for a year or so now, but by comparison, they have been features for about 10 years in most competing RDBMSes.
This article pair got Slashdotted, and some interesting byplay ensued. The general theme was along the lines of
“MySQL is terribly deficient out of the box.”
“Yes, but if you use this new, lightly-documented add-in, that specific problem is now solved.”
Categories: Mid-range, MySQL, OLTP | 2 Comments |
IBM’s mid-range OLTP offering gets strengthened
In the past, when I’ve asked Jeff Jones of IBM for permission to post one of his well-written notes, his response has pretty much been “Of course! Why did you bother asking?” So this time I’m just going ahead and skipping that step. The note is about IBM’s mid-range flavor of DB2, targeted directly at MySQL.
Today, IBM announced that its popular DB2 9 Express-C software is now available with an optional low-cost yearly support subscription. DB2 Express-C has been available without license charges for downloading, application development, deployment and redistribution since January 2006. It remains available without license charges for those that do not require support. Electronic general availability of the new support option is scheduled for June 1, 2007.
The new DB2 Express-C support option provides 24×7 product support, regular fixpacks and upgrade protection. In addition, this option provides support for high availability clustering, offsite disaster recovery, and data replication with remote data servers without additional charge.
Background
— Subscriptions are priced at $2,995 (U.S.) per server per year. This is identical to MySQL Enterprise Gold, but DB2 Express-C includes features not found in MySQL including pureXML support, high availability clustering (MySQL Cluster support costs extra), autonomic features, and no-charge administration and development tools. Unlike the free offerings from Microsoft and Oracle, DB2 Express-C does not place limits on the size or number of databases managed. With up to 4 GB of memory and up to 2 processors, DB2 Express-C can run on more powerful servers, can scale higher and can perform faster than its competitors. Read more
Categories: IBM and DB2, Mid-range, MySQL, OLTP | Leave a Comment |