Какая субд самая быстрая при очень частых SELECT, UPDATE и редких INSERT?

Вероятно имеется в виду на база данных, а СУБД? Хвалили redis.

sqlite in memory

mysql, buttt....

Тупо SELECT по ID и MySQL отлично делает.

Вероятно имеется в виду на база данных, а СУБД? Хвалили redis.

Скорость — это одно, только фанаты Redis как-то не говорят о том, что оно не ACID. Т.е. вот выключат электричество в ДЦ до дампа данных на диск и всё, потеряем данные. Специфическая вещь довольно.

ZopeBD

Python-specific.

Т.е. вот выключат электричество в ДЦ до дампа данных на диск и всё, потеряем данные.

Данные за 30 секунд? В большинстве случаев это не критично. Да и вероятность, что выключат - стремится к нулю. Раз уж пошла такая пьянка, то и вероятность падения атомной бомбы нужно предусмотреть при проектировании приложения.

postgresql

Данные за 30 секунд? В большинстве случаев это не критично.

Всё-таки я бы так не говорил. У всех проекты разные и требования разные. Я как-то в основном сталкивался с такими проектами, в которых за кривые или потерянные данные могут и нехило наказать.

В общем ладно, выбирать ТСу по специфике решаемой задачи. :-)

ну, каждый шаг апдейта должен сохранятся как транзакция. Ну, раз произошло - то это произошло, оно не могло не происходить.

ZopeBD

нельзя так проекты называть..)

redis?

postgresql

два чая этому товарищу

В свое время искал, и пришел к выводу, что все популярные базы медленные на update. Быстрые только всякая экзотика. Но: можно заменить update insert-ом, а это уже быстро много где, например в том же постгресе.

как правило update тормозит - из-за where

Oracle естественно.

Where обрабатывается как обычный select. Если там по индексу поиск, то ничего не тормозит. Дальше затык уже в io, это хорошо видно если отключить fsync, скорость сразу увеличивается. У меня не получилось на моем железе более 50 update в секунду при поиске по pk.

потерянные ладно, если это не за часы. А вот за кривые данные, ручки надо обрывать.

потерянные ладно, если это не за часы. А вот за кривые данные, ручки надо обрывать

+1. И я о том-же. NoSQL решения слишком сильно расслабляют программиста и потворствуют появлению ошибок в самом главном — в данных.

Oracle естественно.

Лол, нет

Ну дык никто и не говорит,что оно во всем лучше. Получаешь одно, теряешь другое.

Ну эка вы загнули, NoSQL ломает данные. Любую технологию нужно уметь готовить.

Ну эка вы загнули, NoSQL ломает данные. Любую технологию нужно уметь готовить.

Какая субд самая быстрая при очень частых SELECT, UPDATE и редких INSERT? (комментарий)

Как мне гарантированно сохранить данные в этом 30 секундном (или в другом, который задаётся вручную) промежутке между последним дампом данных на диск и выключением питания сервера? (Redis.)

Селекты/апдейты без JOIN и обычно по ключу.

Может быть, реляционка вообще не нужна?
Практически любая иерархическая будет быстрее.

да может быть очень кстати, я просто написал какие запросы используются в реляционке. Главное - если данные пришли на апдейт, они должны было 100% на диске. Пару секунд потери обновлений при краше - некритично, но 30 - дофига.

если есть такие требования и такие ограничения, может разумней всего выбрать другую субд?

Redis - быстро, MongoDB - быстро и чаще удобнее чем RDBMS

Осиляторы Оракла говорят что он вообще трансформируется базу данных любого назначения путем применения опытного DBA. Думаю это часто правда, но не всегда. Я сам не могу похвастаться что умею ним пользоваться.

Лол, нет

DB2? :)

oracle + ssd raid0

Правду мы никогда не узнаем, проприетарные БД нельзя бенчмаркать согласно их лицензиям. Точнее можно дома, но публиковать нельзя. Наколенные бенчмарки обычно лажа, даже когда профессиональные не полностью торт.

ладно, ладно, уговорил
тогда, csv + raid0 из 8 ссд на сандфорсах.
правда хз какой контроллер вытерпит это

*сарказм

Это для слабаков. Только сокетный event driven сервер на С со словарем в памяти.

если подцеплена пищалка, то может за 30 секунд можно успеть слить данные на диск?

http://redis.io/topics/persistence читай и восхваляй. Что, однако, не отменяет того факта, что ответ на вопрос ТС-а - PostgreSQL.

Если MySQL в памяти, то выключение электричества тоже критично.

Выбирайте надёжные дц.

Селекты/апдейты без JOIN и обычно по ключу.

Что-нибудь типа «key-value»? Из «олдскульного» - Berkeley DB?

Еще один вариант ответа: LDAP, в варианте openldap еще и репликация из коробки (она, как я понял, вообще в протоколе зашита), как у других - не знаю. openldap в далеком 2004 году на дохлом говне мамонта рвал с места в карьер

Если MySQL в памяти, то выключение электричества тоже критично.

Почему только мускуль?

Я к примеру просто привёл. Любая СУБД в памяти критична к резким выключениям.

Ясно, спасибо.

Я просто относительно начинающий разраб БД, любая информация на этот счёт ценна.

ACID, к указанному, имеет крайне далекое отношение.

В вашем случае для гарантии нужно использовать журналируемую NoSQL, которая вовсе не обязана быть ACID полной, вместо on-memory NoSQL аля упомянутый Redis.

http://www.globalsdb.org/