Opportunity for a Radical Changes in Database Software

Поиск
Список
Период
Сортировка
От Dan
Тема Opportunity for a Radical Changes in Database Software
Дата
Msg-id 1193324732.25145.195.camel@a64
обсуждение исходный текст
Ответы Re: Opportunity for a Radical Changes in Database Software  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Re: Opportunity for a Radical Changes in Database Software  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Opportunity for a Radical Changes in Database Software  ("J. Andrew Rogers" <jrogers@neopolitan.com>)
Список pgsql-hackers
Hi

In looking at current developments in computers, it seems we're nearing
a point where a fundamental change may be possible in databases...
Namely in-memory databases which could lead to huge performance
improvements.

A good starting point is to look at memcached, since it provides proof
that it's possible to interconnect hundreds of machines into a huge
memory cluster with, albeit, some issues on reliability.

For more info on memcached, try:
http://www.socialtext.net/memcached/index.cgi?faq

The sites that use it see incredible performance increases, but often at
the cost of not being able to provide versioned results that are
guaranteed to be accurate. 

The big questions are then, how would you create a distributed in-memory
database? 


Another idea that may be workable

Everyone knows the main problem with a standard cluster is that every
machine has to perform every write, which leads to diminishing returns
as the writes consume more and more of every machine's resources. Would
it be possible to create a clustered environment where the master is the
only machine that writes the data to disk, while the others just use
cached data? Or, perhaps it would work better if the master or master
log entry moves from machine to machine with a commit coinciding with a
disk write on each machine?

Any other ideas?  It seems to be a problem worth pondering since
in-memory databases are possible.

Thanks

Dan




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Datum should be defined outside postgres.h
Следующее
От: Zdenek Kotala
Дата:
Сообщение: Re: Datum should be defined outside postgres.h