|
in reply to Comparison, questions for Postgres, MySQL
When i first started working at Surfari.com with maverick
and eduardo, i asked mav this very question.
We were using MySQL at the time, and he explained that the MySQL people were more interested in speed than features.
Conversely, the Postgres people were more interested in
features than speed. Since we didn't need transactions or
inner selects and we did need speed, maverick chose
MySQL.
Flash forward to now. Postgres has managed to finally catch
up with MySQL in the speed department, but MySQL is still
behind Postgres in the feature department. Me?
I still use MySQL simply from habit, but i still haven't
worked on anything serious enough that requires triggers
or transactions. RI, views, and inner selects are good, but
not completely necessary. If you need them or anticipate
needing them (or any of the other features that Postgres
has), use Postgres. As long as you are using Perl, you will
be smiled upon favorably by the Gods. ;)
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
|
Re: (jeffa) Re: Comparison, questions for Postgres, MySQL
by diotalevi (Canon) on Oct 08, 2002 at 00:25 UTC
|
You know... there is one thing that is either available in non-perl implementations for PostgreSQL that might make me envious of MySQL (assuming it has the feature). asynchronous queries. It galls me that the DBD::Pg driver has to fully complete the PostgreSQL query, copy the data into perl-space and /then/ you can work with it. (it might do lazy copying but that isn't the point). I'd really like it if PostgreSQL got that feature and for some uses that would be a Killer Feature. That's more a function of the existing driver though since PostgreSQL supports it, we just aren't taking advantage of it (yet). Or is there some reason that DBI can't handle aio?
__SIG__
printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::
+svref_2object(sub{})->OUTSIDE
| [reply]
[d/l] |
Re: Comparison, questions for Postgres, MySQL
by Abigail-II (Bishop) on Oct 08, 2002 at 09:46 UTC
|
Since we didn't need transactions
I'm always stunned when I read such a thing. It makes me wonder
why you are using a relational database in the first place.
If you don't use transactions, I guess you don't care about
the integrety of you data. But if you don't care about that,
why have it in the first place?
Abigail
| [reply] |
|
|
Why did we use a relational database... well, there is really a simple answer for that. We didn't for 1/2 of our project, and we did for the other 1/2. :) Let's look at what we built, shall we?
The "project" at surfari consisted off two main products, a website and a search engine. The website needed to keep basic user information, such as username, password, favorite sites, personal bookmarks, etc... Now, I understand your "stunned" outrage at a statement like: Since we didn't need transactions... but, let's analyze why it is that our esteemed friend jeffa would make such a dangerous statement.
When does one "need" transactions? Well, first and foremost, when your data is valuable :) Let's analyze the different dimensions of data that we were storing, and let's see how transactions would have added value...
- User information - Nope... it was a single "add user" button that pretty much just inserted or did not insert a user into the user table. Maverick's code checked the return status of that insert, and it was impossible for the user table to be left in an indeterminate state
- User bookmarks - Well, let's see, you could either remove a bookmark, or add a bookmart to the bookmark table. This consisted of "look up the user id", and "add a bookmark ID to the bookmark table with a fake foreign index to the user id." Hm... doesn't really seem like the data could have been left in an indeterminate state here either...
- Visit tracking - Let's see, each time the user hit a webpage, we stored where they'd come from (thank you HTTP referer!) where they were, etc... we didn't store how long they'd taken to get there, because we could batch process the time dimensionality offline and not negatively impact user experience. So, let's see, another atomic addition to a singular table... yet again, Transactions would not have helped us out here.
- User preferences - Ah, customization! This was going to be what was going to make my 10% of the company in stock options enough to retire... you see, the user would love to spend hours on a shopping mall website setting up their own private color scheme! well, let's see, each time they changed a parameter, an update was fired off to their "customizations" entry for that particular parameter. Hm... another singular atomic transaction. Crap.
Hm... So, why were we using a relational database in the first place?
We were using the ability to store "fake foreign keys" (referential integrity wasn't insured by MySQL, but that's ok, it didn't change the value of our data) with great ease. We had an *incredibly* nice interface to a very customizable persistent data store... We had a really nice query language for our data store... and When we started doing collaborative filtering (Other users that like this stuff liked this other stuff), having it all in a relational database made that development *super fast*! Not to mention that with "time to market" constraints of Internet time, the fact that it provided all of this super duper functionality in an API we all already knew and loved made choosing MySQL a no-brainer. None of the features of the, admittedly incredible, Postgress would have made 1 lick of difference... after all, it's not like we were:
<transaction>
Removing 100 dollars from debit table.
Adding 100 dollars to credit table.
</transaction>
:) God I love classical examples.
So, where didn't we use relational databases? In our search engine! We took a DEC Alpha optimized B-Tree library, put an advanced forest-and-trees tree balancing and distributing decision walker in front of it, added a *sweet* splay-like aging cache mechanism in front of it to alleviate the von-neumann bottleneck, and took advantage of log2(n) as much as we could :)
So... did we care about the integrity of our data? Sure! We were going to retire from the IPO... however, in *many* of the applications I have faced in my professional life, (which granted, have *not* been in the financial sector), all "logical transactions" have been of single statement cardinality.
I advocate right tool for the right job... and in this case, the only reason a relational database was used was the really sweet query interface to a persistent data store, and the handy dandy functionaity provided by auto-increments, indexing, etc... I can guarantee you that any time I see a more complex data model, I reach for a transactional data store...
| [reply] |
|
|
