LINUX.ORG.RU

sqlite in memory

anonymous
()

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

resurtm ★★★
()
Ответ на: комментарий от sin_a

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

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

resurtm ★★★
()
Ответ на: комментарий от resurtm

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

resurtm ★★★
()
Ответ на: комментарий от resurtm

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

alexmaru
() автор топика

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

dizza ★★★★★
()
Ответ на: комментарий от Deleted

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

dizza ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

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

resurtm ★★★
()
Ответ на: комментарий от resurtm

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

dizza ★★★★★
()
Ответ на: комментарий от trashymichael

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

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

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

resurtm ★★★
()
Последнее исправление: resurtm (всего исправлений: 1)

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

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

ABW ★★★★★
()
Ответ на: комментарий от ABW

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

alexmaru
() автор топика
Ответ на: комментарий от resurtm

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

trashymichael ★★★
()

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

vertexua ★★★★★
()
Ответ на: комментарий от anonymous

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

vertexua ★★★★★
()
Ответ на: комментарий от etwrq

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

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

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

*сарказм

etwrq ★★★★★
()
Ответ на: комментарий от etwrq

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

vertexua ★★★★★
()
Ответ на: комментарий от anonymous

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

darkenshvein ★★★★★
()

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

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

yyk ★★★★★
()

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

GateKeeper ★★
()
Ответ на: комментарий от wlan

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

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

Deleted
()
Ответ на: комментарий от resurtm

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.