| Subject | Re: [firebird-support] Re: Firebird and sharding ? |
|---|---|
| Author | Kjell Rilbe |
| Post date | 2012-03-27T20:05:48Z |
Den 2012-03-27 20:04 skrev Ann Harrison s�h�r:
actually just that, nothing more, nothing less.
Would it be unthinkable to add support for such a thing, without also
adding all the "bells and whistles" that would solve every thinkable
situation?
The concept of sharding is new to me, but it seems to me like a feature
that in specific situations can help tremendously with scalability.
Firebird and Interbase seems to have a history of efficient concurrency
with multiple readers *and* *writers*. Isn't that the primary "USP" of
the record versioning/MVCC? But sharding is perhaps more suited for
applications where 99,99 % of the time is spent reading/searching,
perhaps the database is even 100 % readonly except during scheduled
batch updates? In such a situation the ability to automatically split a
simple select query between shards and union the result might be very nice.
On the other hand, I can imagine that the feature could actually be
implemented as a middle tier that does the split & join. But I can also
imagine that this job can be done more efficiently inside the DB engine,
where the SQL text is already parsed and analyzed - instead of doing
that work over again in that middle tier.
That said, I think OP is underestimating the work implied. It's not
enough to implement the feature inside the engine. You also need to
create an interface for it in the client API etc. and/or add
configuration settings to specify the sharding parameters, add suitable
error handling for attempted queries that cannot be performed on sharded
data, and so forth.
The question is if enough Firebird users ("the market") require this
feature to warrant the effort. I think not, but that's just my rather
unfounded opinion.
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
[Non-text portions of this message have been removed]
>Exactly. And as far as I understand, the feature OP requested was
> Yes, for some types of sharded applications all that's needed is the
> ability to produce unions and the relative performance of those doesn't
> matter.
>
actually just that, nothing more, nothing less.
Would it be unthinkable to add support for such a thing, without also
adding all the "bells and whistles" that would solve every thinkable
situation?
The concept of sharding is new to me, but it seems to me like a feature
that in specific situations can help tremendously with scalability.
Firebird and Interbase seems to have a history of efficient concurrency
with multiple readers *and* *writers*. Isn't that the primary "USP" of
the record versioning/MVCC? But sharding is perhaps more suited for
applications where 99,99 % of the time is spent reading/searching,
perhaps the database is even 100 % readonly except during scheduled
batch updates? In such a situation the ability to automatically split a
simple select query between shards and union the result might be very nice.
On the other hand, I can imagine that the feature could actually be
implemented as a middle tier that does the split & join. But I can also
imagine that this job can be done more efficiently inside the DB engine,
where the SQL text is already parsed and analyzed - instead of doing
that work over again in that middle tier.
That said, I think OP is underestimating the work implied. It's not
enough to implement the feature inside the engine. You also need to
create an interface for it in the client API etc. and/or add
configuration settings to specify the sharding parameters, add suitable
error handling for attempted queries that cannot be performed on sharded
data, and so forth.
>All in all, it isn't really a question of valid/useful feature or not.
The question is if enough Firebird users ("the market") require this
feature to warrant the effort. I think not, but that's just my rather
unfounded opinion.
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
[Non-text portions of this message have been removed]