Hi all,
I am looking for fast and reliable database (must be open source)
which is capable of handling millions of rows. It must be fast with
queries.
Basically I need only simple read and write, but with very, very fast
reading capabilities.

Thank You,
Adnan Selimovic.

On Aug 1, 5:22 pm, zavno... (AT) gmail (DOT) com wrote:
For highly specialized applications nothing beats a custom solution.
You might want to consider that.

For more specific answers, could you provide more specific
requirements?
IOW, what is FAST to you?
What is the volume you need? (megabytes? gigabytes? terabytes?)

fuzzy questions tend to get fuzzy answers.

Vague answer to a vague question: look at MySQL and the underlying
storage engine options. But for speed, raw files are faster than
RDBMS.

On Aug 2, 4:53 pm, --CELKO-- <jcelko... (AT) earthlink (DOT) net> wrote:
Yep. All the major open source RDBMS would answer it, as posed...

Furthermore, it's possible to use a custom storage engine with MySQL's
infrastructure. See, for example, case studies on their site:
http://mysql.com/why-mysql/case-studies/
e.g. Fortum's:
http://mysql.com/why-mysql/case-stud...-casestudy.pdf

Thank you all for answering.
I think mySQL is not solution in my case. Currently I am using mySQL
and its pretty slow.
I have tables with millions of rows and up to 10 columns (sensor data
are updated every 2 min and are inserted in table).
I do not need SQL only simple read and write. Maybe something column
based or so.

Sorry for fuzzy question.

Thank you all for answering.
I think mySQL is not solution in my case. Currently I am using mySQL
and its pretty slow.
I have tables with millions of rows and up to 10 columns (sensor data
are updated every 2 min and are inserted in table).
I do not need SQL only simple read and write. Maybe something column
based or so.

Sorry for fuzzy question.

zavnobih (AT) gmail (DOT) com wrote:

<http://www.oracle.com/technology/products/berkeley-db/db/index.html>.

On Aug 2, 8:13 pm, zavno... (AT) gmail (DOT) com wrote:
you still give no definition for what is "pretty slow".

Just one table? Why use a DBMS? just use an indexed file.

If you can define "pretty slow" with some timing measurements, it
would be a lot easier to offer suggestions. (If the application is
hard realtime, a custom file solution will beat a DBMS.)

HTH,
ed

This sounds like the update volume is the problem, not the data base,
per se. Look at solid state storage devices which can handle Tens of
Millions updates very fast.

http://www.texmemsys.com/

They make Digital Signal Processing (DSP) systems. The new XP-30 is
DSP accelerator card that is easily installed in most computers,
residing on a standard 64-bit, 66 MHz PCI bus as a fast coprocessor.

When I did defense contracting, I worked with a man who did atomic
bomb testing. The sensors had to get a huge amount of data in
milliseconds -- after that, there was no sensor left.