>>> 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/
