[development] Database / SQL future thoughts
drupal at mamasam.net
Tue May 5 13:51:08 UTC 2009
On Tue, May 5, 2009 at 11:10 AM, Mikkel Høgh <m at ooh.dk> wrote:
> On Tue, May 5, 2009 at 3:11 AM, Larry Garfield <larry at garfieldtech.com> wrote:
>> On Monday 04 May 2009 3:22:51 pm Yves Chedemois wrote:
>>> Karoly Negyesi a ecrit le 04/05/2009 21:22:
>>> > One comment here.. the field API storage is pluggable.
>>> ... but some work is still needed for this feature to be really usable :
>>> We need people to jump in, here :-)
>> I'd go a step farther and say that the field system backend is not pluggable in
>> any useful sense until/unless it becomes at *least* per-object-type. Per-field
>> is the ideal, but object type is the absolute minimum to call it "pluggable"
>> with a straight face.
>> Larry Garfield
>> larry at garfieldtech.com
> I think we're comparing pears to apples here. This is not a question
> of SQL vs. not-SQL, but more a question of database architecture –
> relational vs. document oriented.
> I think that relational databases will still have their uses with data
> that are inherently relational and carefully structured.
> That is not the way the winds are currently blowing with CCK and
> fields in core where the database schema is mutable and constantly
> evolving, so here the document databases could of help, but so could
> materialized views (not related to Views the module) or sharding.
> It all depends on usage and the amount of time you're willing to spend
> optimising and caching. I don't think that swapping the persistence
> layer out is going to make anything inherently more scalable, and it
> is not the first thing I'd do.
> Look at Facebook – to my knowledge, they're still using MySQL combined
> with memcache and oodles of RAM. Being able to scale to their size and
> no further would be good enough for my usage ;)
Facebook has access to more hardware than the average Drupal developer
and is also using Cassandra
Drupal doesn't really need a relational DB and actually doesn't use
the relational features properly (for example, the way tags are stored
is not efficient). That's one of the reasons why it is slow and
doesn't scale very well.
But going for another storage system would be better if implemented as
a fork, IMO.
More information about the development