В последнее время всё больше набирает обороты движения в сторону отказа от использования обычных баз данных в пользу распределенных или in-memory хранилищ данных. Большие компании (Google, Amazon, Facebook) намекают нам, что традиционные RDBMS уже немодно. Но перед тем как пойти на поводу у них, следует взвесить все за и против.
Пример хорошей взвешенной статьи на эту тему опубликован у Nati Shalom (осторожно, заморский язык).
Если спустится на уровень технических вопросов, то замена SQL сервера на in-memory эквивалент приведет к необходимости "ручками" создавать и поддерживать необходимые вторичные индексы, определять агрегирующие процедуры и многое другое. Интересная дискусия на эту тему происходит у уважаемого мной ЖЖ-юзера Алексея Рыбака. Кстати, там засветились многие интересные авторы, в частности Андрей Смирнов.
Плюс це зовсім інше API. Там використання SQL дуже обмежене. GS за звичай використовують не так як для збереження данних, а для обробки. Якщо цікаво то подивіться до сценаріїв використання processing units.
Щодо
Щодо RDBMS в Google, Amazon, Facebook - тут ситуація інша. SQL бази даних після певного порогу просто напросто не масштабуються. Був на одному проекті де також перейшли до key-value store бо бідняжка MySQL вже не вигрібав і нічого не допомагало. Між іншим про key-value stores - http://www.rozrobka.com/blog/scalability/41.html
Тобто реляційні бази є, були і будуть. Просто після певного розміру системи необхідно буде використати key-value store, або де має сенс
Про GS - познавательно. Вряд ли конечно мне придется когда-либо с ней работать, но для расширения кругозора полезно.
По поводу второй части. Понятно, что описанные выше компании перешли на custom key-value системы не от хорошей жизни -- про ограничения в масштабируемости открытых RDBMS (MySQL,PostgreSQL) известно многим. Этим постом я хоет
Тикет на размер комментария принял. Сорри за неудобство.
Rapid по сравнению с чем ? Порой, оптимизация базы данных для уменшения нагрузки на систему, в целом занимает большой промежуток времени и требует знаний по внутреннему устройству конкретной СУБД. А это уже совсем не "Rapid".