powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Посоветуйте базу, много операция удалений и вставок.
24 сообщений из 49, страница 2 из 2
Посоветуйте базу, много операция удалений и вставок.
    #38890235
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79На самом деле проблем с записью на диск не так уж и много. Допустим 1000 соединений. Создать файл, записать небольшую порцию данных туда, закрыть файл - примерно 0,2 мс, итого до 5000 тысяч мелких файлов в секунду в зависимости от диска. SSD в этом плане побыстрее даже будет.

эээ, что? Нормальный жесткий диск тянет 100-200 IOPS на запись. Т.е. больше 200 атомарных операций не потянет никак. Ну, просто физически seek занимает не меньше 2ms, а скорее 5.
5000 файлов в секунду - это используя кэш ОС, физически при этом ничего записываться не будет.

SSD, конечно, даст 50000 IOPS, но на SSD можно и любую БД использовать в указанном выше режиме, будет нормально )

А вообще магии не бывает, если нужно 800 транзакций в секунду с гарантией независимого сохранения на диск, то или большой рейд-массив или SSD.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890280
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Arm79На самом деле проблем с записью на диск не так уж и много. Допустим 1000 соединений. Создать файл, записать небольшую порцию данных туда, закрыть файл - примерно 0,2 мс, итого до 5000 тысяч мелких файлов в секунду в зависимости от диска. SSD в этом плане побыстрее даже будет.

эээ, что? Нормальный жесткий диск тянет 100-200 IOPS на запись. Т.е. больше 200 атомарных операций не потянет никак. Ну, просто физически seek занимает не меньше 2ms, а скорее 5.
5000 файлов в секунду - это используя кэш ОС, физически при этом ничего записываться не будет.

SSD, конечно, даст 50000 IOPS, но на SSD можно и любую БД использовать в указанном выше режиме, будет нормально )

А вообще магии не бывает, если нужно 800 транзакций в секунду с гарантией независимого сохранения на диск, то или большой рейд-массив или SSD.
Про то и речь. В исходном топике написано - железо подберем. Значит аппаратный энергонезависимый кэш на дисковой подсистеме все вопросы снимает. Так то конечно, если ждать физической записи на диск - без вопросов, долго.

У нас был случай - купили крутые сервера, запустили ПО, тормозило все. Пол года народ в фоне копался, искал проблемы и не находил. Тесты всякие гоняли, ПО переставляли. Все оказалось банально - в поставке батарейки не было, забыли вставить, поэтому кэш диска не работал, все писалось на диск без него.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890416
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Нормальный жесткий диск тянет 100-200 IOPS на запись. Т.е. больше 200 атомарных
операций не потянет никак. Ну, просто физически seek занимает не меньше 2ms, а скорее
5.
А зачем писать в разные файлы, да ещё и по одной записи? Что-то мешает писать в один файл
большими буферами (за исключением отсутствия ИБП)?.. В этом случае скорость достигает
максимально возможной для диска, что никак не меньше 20мб/сек. Информация по сети не будет
успевать приходить с такой скоростью.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890475
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Про то и речь. В исходном топике написано - железо подберем. Значит аппаратный энергонезависимый кэш на дисковой подсистеме все вопросы снимает. Так то конечно, если ждать физической записи на диск - без вопросов, долго.

А, какая разница, где кэш - в дисковой подсистеме или в OC - все равно нужно как-то обеспечивать его надежность. Ну, например, что если говорить о диске - то дисков должно быть два и нужно продумывать, когда и как менять батарейки.
Проблемы с кэшом на дисках встречались.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890485
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3А, какая разница, где кэш - в дисковой подсистеме или в OC
Большая. ОС может потерять данные при выключении питания. На дисках, если есть батарейка, данные не теряются.

Для большей надежности придумали RAID. Если ТС критично, пусть ставит еще и RAID 0+1

Но, по мне, проблема высосана из пальца. Прощу всего, как и советовал Dimitry Sibiryakov, держать данные в оперативке и при выходе писать текущее состояние в файл, при старте - его считывать. На каждый аппаратный сбой не заложишься.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890486
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovА зачем писать в разные файлы, да ещё и по одной записи? Что-то мешает писать в один файл
большими буферами (за исключением отсутствия ИБП)?.. В этом случае скорость достигает
максимально возможной для диска, что никак не меньше 20мб/сек. Информация по сети не будет
успевать приходить с такой скоростью.

Э, по задаче - идет поток мелких update'ов. Увы, но тут если все делать честно, то нужен один seek на каждый update, что и приводит к 200 IOPS.
Можно, конечно, данные хранить только в памяти, на диск писать поток изменений в данных и раз в секунду/минуту/час делать snapshot с данных. Это чуть удорожит recovery, но сильно увеличит скорость записи. Но из коробки это разве что Volt умеет делать, про других не вспомню.

Ну и все равно, при записи потока нет гарантий, что конкретная запись уже успела физически попасть на диск. Например, кэш винта сломался )
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890527
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так нафантазировать много что можно, можно и географически разносить данные на разные континенты, и Failover кластера создавать и так далее. Вопрос цены :-)
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890543
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Э, по задаче - идет поток мелких update'ов.
С какого перепугу "удаления и вставки" превратились в "update"? У автора примитивная
очередь, которую он по глупости собирался реализовать в БД.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890625
ээээээ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DPH3Arm79На самом деле проблем с записью на диск не так уж и много. Допустим 1000 соединений. Создать файл, записать небольшую порцию данных туда, закрыть файл - примерно 0,2 мс, итого до 5000 тысяч мелких файлов в секунду в зависимости от диска. SSD в этом плане побыстрее даже будет.

эээ, что? Нормальный жесткий диск тянет 100-200 IOPS на запись. Т.е. больше 200 атомарных операций не потянет никак. Ну, просто физически seek занимает не меньше 2ms, а скорее 5.
5000 файлов в секунду - это используя кэш ОС, физически при этом ничего записываться не будет.

SSD, конечно, даст 50000 IOPS, но на SSD можно и любую БД использовать в указанном выше режиме, будет нормально )

А вообще магии не бывает, если нужно 800 транзакций в секунду с гарантией независимого сохранения на диск, то или большой рейд-массив или SSD.горизонтальный шардинг ? по диапазонам 'id'.

например plproxy в постгрес-куку-эл.
но таблицу логических блокировок (с восстановлениями после сбоя) удобнее вести, сюрпрайс, на блокировочнике. В версионнике мусор чистить замахаешься.
но там я давно не был -- есть ли такие же удобные шардеры -- не знаю.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38890828
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3...эээ, что? Нормальный жесткий диск тянет 100-200 IOPS на запись. Т.е. больше 200 атомарных операций не потянет никак. Ну, просто физически seek занимает не меньше 2ms, а скорее 5....
а не надо делать seek.

если писать последовательно в файл, как например все нормальные базы redo (информацию для восстановления) пишут, проблем со скоростью не будет
Dimitry SibiryakovС какого перепугу "удаления и вставки" превратились в "update"? У автора примитивная
очередь, которую он по глупости собирался реализовать в БД.

Но даже в отличие от примеров из I-net "очередей" на таблицах в БД, у него еще какая-то достаточно сложная логика на update'ах

Если бы только insert/delete, подозреваю, было бы быстрее. Плюс, явно все update работают serialized и блокируют друг друга, возможно, сделать ручную блокировку (типа пакета DBMS_LOCK в Oracle) и забыть про "так делается для того, чтобы одну и ту же запись не могли получить одновременно два разных соединения".

Хотя с масштабированием такого решения конечно полная засада (но и у автора не лучше).

Лично меня удивляет, что БД выдерживает 400-800шт в сек. На мой взгляд, для такого потока операций это очень много.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38891062
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Arm79]DPH3А, какая разница, где кэш - в дисковой подсистеме или в OC
Большая. ОС может потерять данные при выключении питания. На дисках, если есть батарейка, данные не теряются.
[quot]
Ты не поверишь, для ОС тоже есть батарейка - ИБП называется ;)
И, кстати, зачастую дешевле, чем дисковая система с встроенной батарейкой для кэша )

Но, по мне, проблема высосана из пальца. Прощу всего, как и советовал Dimitry Sibiryakov, держать данные в оперативке и при выходе писать текущее состояние в файл, при старте - его считывать. На каждый аппаратный сбой не заложишься.
Ну, это-то да. Но может там что-то принципиально важное-важное )
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38891092
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Но может там что-то принципиально важное-важное )
В этом случае его стоит писать в плоский файл сразу по получению. Всё равно получится
быстрее чем с любой СУБД.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38912199
Artemeey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Artemeeyпропущено...


Спасибо! ТАРАНtool мне показался интересным и вероятным решением из NoSQL.
На самом деле проблем с записью на диск не так уж и много. Допустим 1000 соединений. Создать файл, записать небольшую порцию данных туда, закрыть файл - примерно 0,2 мс, итого до 5000 тысяч мелких файлов в секунду в зависимости от диска. SSD в этом плане побыстрее даже будет.

Но и это можно обойти и ускорить. Например, выравнивая приходящие сообщения по размеру и записывая их в файл (но не закрывая сам файл) с принудительным сохранением буфера. Тогда не будет тратиться время на получение соответствующего handle, а удаление записи - обычной пометкой как удаленную. При новых сообщениях (учитывая, что они равны в размерах) тупо писать на место помеченной как удаленная либо добавлять в конец.

И, естественно, вести в памяти индекс, например на основе avl деревьев. То есть такая своеобразная localdb получится.

Работы там на пару дней всего + еще пару - тестирование.

У каждого потока есть свой id и время работы, чтобы записанные данные изолировать от других потоков.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38912336
churupaha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Artemeey, рассмотрите

In-Memory OLTP
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38912829
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3Если я правильно понял, тут какой-то аналог очереди раздачи заданий.
Поищите любую очередь сообщений с гарантией доставки (если это так важно) и не мучайте БД )

Вообще, если задача - просто распределять таски по воркерам (иногда там встречаются подобные решения), то лучше использовать базу с реализацией skip locked.
угу, чистая очередь.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38912935
churupaha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...очередь

Service Broker, Queue

или свой лисапед

READPAST
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38925201
Фотография Vovaka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoltDB посмотрите
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #38936223
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В postgresql для организации систем обслуживания есть такие вещи как
совместные блокировки. Очень быстрая штука.
Table 9-73. Advisory Lock Functions
http://www.postgresql.org/docs/9.4/static/functions-admin.html
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #39015990
Artemeey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем спасибо. Решение было найдено. MySql стал справляться с нагрузкой. Логика была переписана.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #39016639
vlommer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Artemeey,
Есть СУБД, рассчитанные на аццкий поток вставок, в основе которых лежат структуры данных типа log structured merge tree. Это HBase, LevelDB и многие другие.

Не разбираюсь в том, какой язык запросов в каком из них работает.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #39016646
vlommer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Во многих LSM-движках надежность обеспечена WAL-журналом или даже самой основной структурой данных, где WAL есть первый уровень данных.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #39029510
golovonometr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
обычная очередь, с персистентными сообщениями, без каких либо баз данных. Перезагрузка оставит сообщения в очереди, падение соединения с клиентом тоже. При восстановление коннекта работа может продолжится с этапа сруба процесса.

как он хочет это на mysql - непонятно... Все поаплодируйте ему стоя!
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #39112448
Artemeey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
golovonometr,

Что значит без каких либо баз данных, а место хранение этой очереди где будет?
Я видимо не совсем понял, что вы имеете ввиду. Подскажите, пожалуйста решение.

Так же в этой очереди должны храниться результаты обработки и статус самой задачи.

P.S. Вопрос закрыт, задача решена.
...
Рейтинг: 0 / 0
Посоветуйте базу, много операция удалений и вставок.
    #39112559
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Artemeeyа место хранение этой очереди где будет?
ОЗУ.

Artemeeyв этой очереди должны храниться результаты обработки
А вот это в очереди ни к чему. Ты же не собираешься в очереди держать уже обработанные задания?..
...
Рейтинг: 0 / 0
24 сообщений из 49, страница 2 из 2
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Посоветуйте базу, много операция удалений и вставок.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]