>>> But realize that there are very real problem with those types of
>>> >analysis solutions when dealing with OLTP databases -- otherwise there
>>> >would be solutions
>>> available (that don't have license fees that are>more than the total
>>> sending cost of sending a child to a US Ivy League>school for 4 years).
>
>> yes i understand, but now with my 50 millions rows table i start to meet
>> the limit of firebird where a simple prepare can take around 1 s to 1 min
>> dependantly the
>> charge of the server (see my previous post). next year it's will be around
>> 100 millions rows and i will have no solutions ... this why i start to
>> thing about sharding in
>> an easy way, in a way out in fact
>
> I am not sure what your purpose of your DB is, but if I recall correctly you
> did something with session data in this big table. Perhaps for that purpose
> the use of another database like one of the noSQL database is better.
>
> I read some article shortly ago about a big site with a lot of trafic. They
> migrated their session data to a noSQL DB (I believe MongoDB) because of the
> nature of the data. They gained a lot of performance doing that.
>
> The concept of these noSQL databases is not clear to me yet (I am not a DB
> specialist) but I do read a lot about sites migrating parts to these kind of
> database from a former relational database like Firebird. One of the
> examples mentioned often is historical data that is moved to these noSQL
> databases.

In a current project I'm involved in, storing measurement values from a
vast amount of devices around the world, we are prototyping an
implementation using a NoSQL database (HBase; distributed wide-column
key/value store), as we can't use the relational technology to manage
data in the TB/PB area including automatic scale-out by adding
additional nodes in a cluster.

We still intend to use a relational backend for storing aggregated data,
because data volume is smaller and access through SQL and/or various
client application types (OLAP client etc.) is better/easier when going
to a RDBMS, but for the pure raw fine-grained measurement values, a
NoSQL solution makes sense for our requirements.

In short: NoSQL currently lacks of important RDBMS concepts like ACID
transactions, referential integrity etc., so it's not a good idea to use
a NoSQL database for e.g. a POS system. NoSQL and in particular HBase is
good in scale-out scenarios, so scalability is one major advantage over
a RDBMS, when it comes to managing a large amount of data and processing
large sets of data in *parallel*.

NoSQL vs. RDBMS might change with NuoDB, as it promises to be a scalable
(scale-out) transactional (ACID) database system. Anxious to see how
this works in practice, especially in context of the CAP theorem.
Interesting time for DBMS geeks is coming along. ;-)



--
With regards,
Thomas Steinmaurer (^TS^)
Firebird Technology Evangelist

http://www.upscene.com/

Do you care about the future of Firebird? Join the Firebird Foundation:
http://www.firebirdsql.org/en/firebird-foundation/