Хочу поделиться нашими свежими цифрами по использованию dets В базу данных

Question

Хочу поделиться нашими свежими цифрами по использованию dets В базу данных

пишется неширокая строка: имя потока, имя файла, таймстемп.

в код закралась ошибка и база данных выросла до гигабайта. Там оказалось 7 млн записей, смешная цифра то.

Скрипт который удалял их и оставил около 8 тыс, работал на среднем компе 2 часа и оставил 1,2 гигабайта (!)

Потребовалось файл закрыть и переоткрыть с force,true, чтобы через какое-то ощутимое время получилось 64 мегабайт.

Выходит, что если бы мы просто на каждую запись писали на диск большой жсон, это было бы в целом лучше и эффективнее, чем специализированная БД.

Это вообще нормально?

#erlang #it #programming #russian

0

09.08.2024

19 ответов

15 просмотров

Maksim Lapshin Автор вопроса

Lama Lover
Специализированная бд это вы про dets?

да

0

1 месяц назад

Lama Lover

Maksim Lapshin
да

Так dets уже давно не рекомендован к использованию, даже в OTP, если я не ошибаюсь. Я обычно варю ets, которая по таймеру на диск синкается.

0

1 месяц назад

Maksim Lapshin Автор вопроса

Lama Lover
Так dets уже давно не рекомендован к использованию...

Те "дампим жсон на диск"?

0

1 месяц назад

Dmitry Frolov

Используем ets + кастомный wal-log изменений, чтобы не протерять данные в случае внезапного ребута системы. Сейчас выявились проблемы при работе системы, когда диск закончился, но в других случаях не имеем проблем ни со скорость восстановления ни с чем другим

0

1 месяц назад

Igor Karymov

Да грустно. По современным меркам это вообще не объёмы.

0

1 месяц назад

Maksim Lapshin Автор вопроса

Dmitry Frolov
Используем ets + кастомный wal-log изменений, чтоб...

Те руками пишешь wal по сути append log бд вручную?

0

1 месяц назад

Dmitry Frolov

Maksim Lapshin
Те руками пишешь wal по сути append log бд вручную...

Да имеено так. Безотказный вариант

0

1 месяц назад

Maksim Lapshin Автор вопроса

Dmitry Frolov
Да имеено так. Безотказный вариант

Немного отдает "сходить набрать песка для запекания своего кремния" :) Интересно вот что: sqlite тоже очень тормозной. Что принципиально иного в постгресе, что он настолько быстрее? Хранение в памяти?

0

1 месяц назад

Vladimir Sekisov

Если ключи можно держать в памяти, то bitcask довольно быстрый и весьма надёжен, потому как база на диске просто wal, а в случае чего совсем плохого индексные файлы из этого wal легко восстановить.

0

1 месяц назад

Δημήτηρ

Vladimir Sekisov
Если ключи можно держать в памяти, то bitcask дово...

А если нужно держать данные на дичке?

0

1 месяц назад

Vladimir Sekisov

Δημήτηρ
А если нужно держать данные на дичке?

Наверное, я непонятно написал, bitcask не может быть disk only. Индекс ключей всегда грузится в память весь.

0

1 месяц назад

Oleksiika

Vladimir Sekisov
Наверное, я непонятно написал, bitcask не может бы...

Тут проблема в другом. Если в момент падения ноды идет запись данных, то при поднятии ноды станет очень грустно сначала девопсам, а потом и нам.

0

1 месяц назад

Vladimir Sekisov

Oleksiika
Тут проблема в другом. Если в момент падения ноды ...

Тк база просто wal, те append only,она всегда восстановится, хоть и с потерей последних данных, но тут даже Oracle их потеряет.

0

1 месяц назад

Maksim Lapshin Автор вопроса

Vladimir Sekisov
Тк база просто wal, те append only,она всегда восс...

а у wal-ов что-то кроме снепшотов есть для того, чтобы не давать сквида на старте?

0

1 месяц назад

Vladimir Sekisov

Maksim Lapshin
а у wal-ов что-то кроме снепшотов есть для того, ч...

Если говорить о bitcask, то он дробит wal на сегменты и скидывает периодически индекс на диск. Потому восстановление зависит от того, погиб индекс или нет.

0

1 месяц назад

Maksim Lapshin Автор вопроса

Vladimir Sekisov
Если говорить о bitcask, то он дробит wal на сегме...

индекс или полное состояние базы?

0

1 месяц назад

Yuri Pipchenko

Vladimir Sekisov
Если говорить о bitcask, то он дробит wal на сегме...

А удаления и апдейты записей как делаются?

0

1 месяц назад