| 1.1, AlexAT (ok), 23:24, 01/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Встраиваемое KVS с Acid и транзакциями - это пять. Надо поприглядеться.
| | |
| |
| 2.7, alexpn (ok), 05:44, 02/02/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Интересно посмотреть нагрузочное тестирование
и желательно сравнение с монстрами
PS MSSQL монстром не считаю ..... скорее пародией на БД
| | |
| |
| 3.9, ACCA (ok), 06:24, 02/02/2015 [^] [^^] [^^^] [ответить]
| –4 +/– |
 Ты неправ. У него есть HandlerSocket, для k-v хранилищ гоняться с ним сложно, разве что новейший PostgreSQL. Всякие MongoDB и memcached нервно курят в сторонке.
| | |
| |
| 4.11, Аноним (-), 09:02, 02/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>PS MSSQL монстром не считаю ..... скорее пародией на БД
> У него есть HandlerSocket,
Вы точно про mssql, а не про mysql?
| | |
| |
| 5.32, alexpn (ok), 18:17, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Всегда ломал голову ну что надо маздайцам на форуме по открытым технологиям ????
Или что Вас забанили на MiCrOsOft.com ????
| | |
| |
| 6.34, Вожатый (?), 11:26, 03/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Всегда ломал голову ну что надо маздайцам на форуме по открытым технологиям ????
Open Source != Linux или *BSD
| | |
|
|
| 4.20, Аноним (-), 10:36, 02/02/2015 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> для k-v хранилищ гоняться с ним сложно, разве что новейший PostgreSQL.
Даешь гонки феррари и карьерных самосвалов! :)
| | |
| |
| 5.24, Вулх (?), 11:26, 02/02/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
выиграть могут как те так и другие, всё зависит от трассы. Более того можно подобрать трассу когда шансы будут примерно равны.
| | |
|
|
| 3.12, Аноним (-), 09:07, 02/02/2015 [^] [^^] [^^^] [ответить]
| +6 +/– | |
>и желательно сравнение с монстрами
Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?
| | |
| |
| 4.13, AlexAT (ok), 09:14, 02/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?
Народ просто не понимает, зачем оно. А мне вот допустим недавно понадобилось очень шустрое межсеансовое хранилище для *локальных* переменных, коих сотни тысяч штук, но с блокировками и транзакциями. Смотрю пока на sqlite3, но мне оно кажется слишком громоздким.
| | |
| |
| 5.15, Аноним (-), 09:46, 02/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
у sqlite изоляция транзакций serializable. и при записи блокировка ставится на всю базу. и никакого mvcc, не для этого она создавалась.
| | |
| |
| 6.16, AlexAT (ok), 09:50, 02/02/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
Блокировка в sqlite3 во время транзакции ставится т.н. "reserved", не "exclusive", т.е. читатели в это время могут продолжать работать. MVCC при этом в sqlite3 есть, 1W/*R. В принципе для моей задачи это вполне подходит (у меня чтение в сотни раз преобладает над записью), но KV хранилище подошло бы куда лучше.
| | |
|
| 5.19, Аноним (-), 10:35, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> но с блокировками и транзакциями. Смотрю пока на sqlite3, но мне
> оно кажется слишком громоздким.
Если что, скулайт на запись могет только 1 writer'а, оверхет от сиквеля никто не отменял, да и очень шустрым его назвать сложно. Если надо хранить нечто хорошо накладывающееся на логику key-value (переменная-значение по идее неплохо в это вписывается) - key-value скорее всего будет резвее и без лишней возни. Кстати бывает еще такая штука как tokyo cabinet. Помонструознее сабжа немного. Но авторы оного не зря хвастаются скоростью и прочая.
| | |
| |
| 6.39, AlexAT (ok), 08:57, 18/04/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Таки перевёл систему на SQLite3. Мне у SQLite3 в моём применении не понравилось только одно: каждая транзакция вызывает генережку отдельного логфайла. Да, там есть режим "сохранять логфайл", но всё равно он как-то так с ним работает, что на shared FS (GFS2) его не разместить - дикие тормоза. Впрочем, в моём случае это не критично.
Увы, ни Tokyo, ни Kyoto Cabinet - не умеют MVCC... в моём случае нужна поддержка consistent read, и желательно без блокировки reader'ов при записи.
| | |
|
| 5.37, Igel (??), 16:21, 14/04/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Народ просто не понимает, зачем оно. А мне вот допустим недавно понадобилось
> очень шустрое межсеансовое хранилище для *локальных* переменных, коих сотни тысяч штук,
> но с блокировками и транзакциями. Смотрю пока на sqlite3, но мне
> оно кажется слишком громоздким.
встраиваемыfirebird
| | |
|
| 4.21, Аноним (-), 10:38, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?
Что характерно - key-value базы по скорости имеют свойство сильно втыкать SQL'ным, хотя-бы из-за отсутствия оверхеда. Но с другой стороны, выписывать сложный запрос для бизнес-аналитики самолично раскладывая все на формат ключ-значение...
| | |
| 4.23, fidaj (ok), 10:43, 02/02/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >>и желательно сравнение с монстрами
> Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?
даешь сравнение sohpia vs bdb vs kyoto cabinet! :) они встраиваемые ;)
хотя две последние не являются в полном смысле СУБД - они скорее просто БД... есть подозрение что и САБЖ тоже.
| | |
|
| 3.14, edwin3d (ok), 09:20, 02/02/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Интересно посмотреть нагрузочное тестирование
> и желательно сравнение с монстрами
> PS MSSQL монстром не считаю ..... скорее пародией на БД
Знаете, не стоит так вот показывать свое непонимание изначальной концепции продукта.
https://ru.wikipedia.org/wiki/%D0%92%D1%81%D1%82
Почитайте, пожалуйста, эту ссылку и обратите внимание на особенно и сферу
| | |
| |
| 4.18, Аноним (-), 10:32, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Почитайте, пожалуйста, эту ссылку и обратите внимание на особенно и сферу
Ну как бы чисто номинально у MS была какая-то сильно обкоцаная версия для именно встройки в приложения. Но правда у MS даже это получилось нехилым монстрятником, где никакой речи о "паре файлов на си" и близко разумеется не идет.
| | |
| 4.36, alexpn (ok), 04:40, 04/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Понимание как раз полное
Отличие БД представляется
под словом МОНСТРЫ понималось sqlite и Berkeley
Но никак не MSSSSS
Вообщем сам сравню при случае ....
| | |
|
| 3.17, Аноним (-), 10:30, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> и желательно сравнение с монстрами
А давайте лучше сравним феррари с карьерным самосвалом? :)
| | |
|
|
| |
| 2.28, Дмитрий (??), 14:21, 02/02/2015 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Думаю многие не понимают что насамом деле представляет из себя LMDB и его худший случай. Дело в том, что LMDB при интенсивных обновлениях начинает переиспользование старых странниц. Со временем производительность падает до классического B-дерева на вставку (а это рандомное обращение к диску на запись + эффективность кеширования). LMDB отлично работает на базах которые не сильно больше чем оперативная память. Бенчмарки обычно отличные, потому что используется mmap и бенчмарки на смешное кол-во данных.
Автор делал бенчмарк с LMDB и можете посмотреть чем это закончилось: https://github.com/pmwkaa/sophia_benchmark/issues/2
Это большая архитектурная проблема.
| | |
|
| 1.26, Аноним (-), 12:45, 02/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Для работы требуется только два файла на языке Си.
Странное заявление. На GitHub файлов значительно больше.
| | |
| |
| 2.29, Аноним (-), 14:27, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> Для работы требуется только два файла на языке Си.
> Странное заявление. На GitHub файлов значительно больше.
Похоже что там amalgamated сборка, по аналогии с sqlite. Создается новый Си-файл.
| | |
| |
| 3.35, й (?), 20:40, 03/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
А зачем это делается? Ведь линковка десятка obj-файлов -- это ничего в сравнению с пересборкой и линковкой всех (даже если это один файл) в случае изменения одного из них. Чисто выпендриться, какие мы крутые и embedded-friendly?
| | |
|
|
|
