Keeping Google's In-house Database Ticking

An anonymous reader writes "ZDNet has a short but interesting piece on the what Google did with its 12GB database when it became a challenge for the finance department. The database was split into three, says Chris Schulze, technical program manager for Google — one for the current financial planning projections, one for the actual current data from existing HR and general ledger systems, and one storing historic information. The article says Google has been using a variety of products from Hyperion (recently bought by Oracle) to manage its internal financial systems since 2001."

Comments

Re:WTF WTF?

[pasamio]

Its an advertisement! Read the bottom: "Angus Kidman travelled to Orlando as a guest of Hyperion". The thing mentions Hyperion a dozen times, its the old trick of substituting news with press releases written by companies.

Only 12 GB?

[operagost]

12 GB? You call that big? I haven't seen an Exchange mail store that small!

Only 12GB?

[WapoStyle]

I don't get it, that doesn't seem like much to me.

We have many databases that are larger here from MSSQL to Oracle, some around the 600GB mark.

What's so special about Google's database?

Re:Only 12GB?

[ms1234]

What's so special about Google's database?

Google.

Re:Only 12GB?

[alxtoth]

TFA is about a _cube_ of 12 Gb . Not _relational_ database. Read my other post http://developers.slashdot.org/comments.pl?sid=232 481&threshold=1&commentsort=0&mode=thread&pid=1889 9385#18899875

Re:Only 12GB?

[hemp]

Google's Hyperion database is an OLAP ( on-line analytical processing ) database rather than an OLTP ( on-line transaction processing ) database. OLAP databases are optimized more for processing human queries rather than standard transactions (like most MSSQL and Oracles are). Hyperion incorporates multi-demensional data hierarchies and other data formats that are difficult if not impossible to model in straight SQL(think of a Rubik's cube in 7 demensions).

The downside of this approach is that it can cause lengthy time periods when the cubes needs to be re-calculated. In Google's case, evidently, this took 48 hours.

Re:WTF WTF?

[eln]

It's not only a press release, it's a very unimpressive one. Hyperion can handle data larger than 12 GB?! Stop the presses! You could manage a company of 50, maybe even 60 employees with that!

Plus, the "story" says that in order to manage such a large (*cough*) amount of data, the solution was to partition the database into 3 different parts. Now, I can see partitioning it for ease of management along functional areas, but certainly not because it grew to 12 whole gigabytes. If you can't handle chunks of data larger than 4 GB without partitioning it, you're in big trouble.

I'm guessing the "anonymous reader" who submitted this works for Hyperion.

Err..yeah...it's really a Hyperion ad

[kiwimate]

This is the bit that gets me in the summary:

ZDNet has a short but interesting piece

Interesting to whom, precisely? Hyperion's marketing department? Scant technical details and really only notable for the link to the photos of Google's new Sydney office which are kind of interesting, I suppose, in an "ooh wow shiny...okay what's next?" kind of way.

Press release

[gtoomey]

1. Move on, nothing to see
2. Sack Zonk (sorry man you post some good stories, this ones a stinker)

12 GB is not 12 gigs.

[nathan s]

Obviously that's 12 GOOGLE-Bytes*. Which are far huger than ordinary bytes, or even gigabytes, and therefore much more interesting.

* Note that GoogleBytes are still in beta and therefore the exact amount of storage in a single GB is yet to be determined.

Re:It's Google

[icepick72]

The tricky part isn't managing every command passed by tens of thousands of users

It's not tricky, you just have to be really really fast!

OLAP is a different beast

[alxtoth]

12 Gb of _relational_ database falls under "nothing to see, move along". But Essbase http://en.wikipedia.org/wiki/Essbase is doing OLAP http://en.wikipedia.org/wiki/OLAP , which means that data is pre-aggregated across multiple _hierarchies_ . Those 150 users are likely the top management looking at the revenue, or reviewing the budget.
In Open Source land there are similar projects: http://freshmeat.net/search/?q=olap&section=projec ts

You think GB Stands for Gigabytes!?

[VE3OGG]

No no no! It stands for Googlebytes. Each Googlebyte is approximately 1024x10^10,241,024 bytes. So as you can see, a 12 Google Byte database is quite substantial...

Glitch in the Matrix

[suv4x4]

FTFA:

The database grew in size to more than 12 gigabytes, and the period restructuring required to ensure accuracy could see the system, which is now used by more than 150 staff, taken offline for two hours at a stretch.

"Right now, we're on a not very powerful Windows box," Couglin said.

Uhmm, maybe it's some other Google, right...?

I can't be reading a press release from Google, the one that has more or less a copy of the whole Internet on its servers, whining about the difficulties of managing a small database on a slow Windows machine.

Oh, my!

[Jerky McNaughty]

So Google used horizontal partitioning to split load across servers? Wow, that's rocket science. None of us in the database community have thought of doing this before. :-) But, if you want to find some news here, you can. One nice thing that Google did recently was to donate their horizontal partitioning code for Hibernate to the open source community. Hibernate Shards definitely needs a lot of work to get it to the point where it does a lot of stuff that people would want, but, hey, release early and often!

Re:12gb?

[yahooadam]

you can practically gather from the summary, without even RTFA that this is talking about google's financial database, which is most likely used to find out how Google is doing, nothing to do with the services Google offer the public