Hacker News new | past | comments | ask | show | jobs | submit login

I think you are overgeneralizing IMS performance. "IMS is extremely old and very slow. Searching for data can take hours." Especially when you later point out that they have 10TB of DB2 data and probably more than that in IMS. Not all IMS databases are slow. Not all MySQL / Postgres, etc. databases are fast.

Definitely not! I'm mostly quoting what she said, but IBM has a lot of nice tech, but you have to understand that these are very old versions of IMS and the volume of data they have does not make the case better. Hierarchical databases are not always slow, but once you want to find stuff at the very bottom of the hierarchy, it'll start take some time.

Hierarchical and network DBMSs can scream, but you have to have a competent DBA curate the so-called "physical" relationships (indexes, record and index pointers, child record locality, block sizes, buffers, what-have-you) that support the logical views defined by the application schema. In either IMS or IDMS (where I have some experience) this can be a lot of work, done right. Measure, tweak, repeat. Those older DBMSs can be finicky, but properly monitored are great performers.

Conversely, a lazy DBA can cost you a lot of money. And lazy DBAs can be hard to identify - their domain is rather arcane after all.

Um, what about indexes?

These older databases often allow the use of indexes as an option. Of course ISAM (Indexed Sequential Access Method) is indexed. But also it is often possible to add indexes to the networked database internal structures. An alternative is to use hash tables with overflow. In any case you must usually periodically scan through the database reorganizing the indices and/or location of records, which can take up a lot of time and usually requires taking the database offline. Here's a good read(first is PDF):


or the same paper at Google Books:


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact