Схему привёл в цитатах чуть ниже по тексту. Про скорость, кстати, и упоминать не стану, т.к. на этот показатель сильно влияет CPU, шина и, конечно, дисковая подсистема. Если и приводить цифры, то только в сравнении нескольких БД на одной аппаратной платформе. Но, если честно, это выходит за рамки практических нужд — выбор нативного решения под сишное приложение сильно ограничен, а уж эрланговские и явовские БД кроме чувства брезгливости никаких положительных ассоциаций не вызывают.
В любом случае хочу Вам пожелать успеха в проекте. Продолжайте. Вы делаете полезное дело и пусть конкуренты не смущают — когда-то и про существование Линукс знала пара-тройка энтузиастов ;)
Вы совершенно правы. Было и отключение журналирования, и вставка вообще реализована без транзакций, маленькими порциями (если я всё правильно помню).
Т.к. это временной ряд, то при аварийном завершении приложения всегда можно подсмотреть время последней успешной вставки и недостающее подтянуть из внешнего «кеша». Помимо прочего, версия SQLite позволила реализовать consequtive disk access, а в момент старта приложения средствами SQLite производится проверка базы на консистентность pragma integrity_check. В общем, был реализован ряд мер, обеспечивающий и производительность, и надёжность для последовательной записи и обращений к временному ряду. Скорость выборок и вставки вне конкуренции с другими упомянутыми мной БД.
А вот и обещанная схема, она предельна проста. Одна отдельная БД с одной таблицей:
Да, 400 млн строк в одной таблице. Во всей БД только одна таблица. Что-то колдовали с опциями для быстрого добавления. Что именно, сейчас не помню. Доберусь до кода — вышлю схему.
Но, почему-то, всегда получается так, что те приложения, для которых требуется беспрецедентно высокая производительность написаны именно на Си. Примеры навскидку: Redis, Postfix, Dovecot, PostgreSQL, SQLite. Их близкие конкуренты, написанные на плюсах, уже несколько меркнут ))) Хоть и нельзя утверждать, что тот же MySQL стал бы лучше PostgreSQL, если бы был переписан на Си.
Потому, что быстрее просто не удалось найти. Проводился целый ряд исследований под конкретную потребность — хранение временных рядов (среди основных задач). Хочу особенно подчеркнуть, что каждая БД хороша под свои цели. При нагрузочном тестировании рассматривались BerkeleyDB и PostgreSQL в т.ч.
BDB отпала по двум причинам:
1. Она «не SQL» — там своя атмосфера. Дизайн API очень запутанный и странный.
2. Не имеет преимуществ по производительности в сравнении с SQLite.
Производительность PostgreSQL под требуемую задачу не идёт ни в какое сравнение с SQLite. SQLite доступен напрямую как сишная библиотека, которую можно статически собрать с приложением. К PostgreSQL доступ только по сокетам. PostgreSQL хороша для проектов с многопользовательской нагрузкой, с доступом к случайным фрагментам БД и сложными выборками. А для последовательного доступа к данным от имени одного приложения (как в случае с временными рядами) лучше, чем SQLite найти не удалось.
Возможно, где-то MySQL и является преимуществом, но не в научных задачах. По производительности она вообще не конкурент.
Насчёт кофеварок Вы погорячились ) SQLite полноценная БД со своими киллерфичами. Одна из самых быстрых и, кстати, среди прочего, умеет вложенные запросы, in-memory, и много того, чего не умеет MySQL, несмотря на свою «зрелость» и «корпоративную поддержку».
То-то у меня подозрения по поводу эрланга возникли… Со своим гарбидж-коллектором и виртуальной машиной оно вообще тормознутое для больших кусков данных, хранящихся в памяти.
Спасибо за интересную ссылку. Парадоксально, что пишут «высокопроизводительные» базы на каких-то низкопроизводительных языках программирования. Во всём обзоре в лучшем случае использовался C++. Нет ни одной базы на чистых сях.
Попробуйте переписать на чистый Си. В результате ещё больше увеличите производительность и проект будет выглядеть конкурентоспособнее по сравнению с Click House.
К статье привлекли слова «time series база данных». Но там, где встречаю такие громкие заявления, как «Высокопроизвоидительная» в сочетании с «Erlang» закрываю не читая.
Если вы делаете 10 000 вставок в свою SQL базу данных — все будет хорошо какое-то время, потом таблица вырастет в размерах настолько, что время выполнения операций вставки увеличится.
Пруфлинк в студию, пожалуйста!
Работаю в научной сфере с временными рядами без изысков и экзотики, используя банальную, хорошо настроенную SQLite. На 400 млн строк упомянутой у Вас просадки производительности для insert не наблюдается.
Вообще, хотелось бы увидеть сравнительные тесты разных БД с Вашей разработкой. SQLite в частности.
В результате прочтения статьи можно прийти к выводу, что нет ни одного опенсорсного антивируса кроме топорного Clamav, у которого уже лет 20 нет проверки в режиме реального времени. Убогий прожорливый интерфейс на TK с нулём функций как не был никому не нужен раньше, так и остаётся таковым по сей день.
Clamav с начала времён страдал низкой угадываемостью вирусов. Не верите? Вложите eicar в zip и этот zip в другой zip. Всё! Клам даже не попробует проверить глубже одного вложения.
Вся остальная проприетарщина — софт для шпионажа. Не верите? А кто докажет что это не так без сорцов?
Итоги. Антивируса под Linux не было и нет. Контейнеризация или SELinux и… фух, оказывается антивирус и не нужен!
IBM Notes — тот ещё монстр. Тормознут, убог и ужасен как для администрирования, так и для программирования. Проприетарен, сорцы закрыты. Лицензии стоят чуть ли не 200-300 USD за каждого пользователя. Про шило и мыло — в точку.
До раскулачивания политика банка была направлена на opensource. Из утверждения BeppeGrillo можно понять, что Приватбанк переходит с Linux на Windows. Или это домыслы?
И много Вам этот эникейщик навиндит?! Exchange в кластере? ADшку настроит и юзеров по OUшкам раскидает? ГУЙ для HR'а настроит, чтобы при увольнении заблокировать пользователя? Права повыдаёт? Если нет, то зачем он вообще такой. Проще «приходящего» по звонку профи. По деньгам то же, зато не будет наступать на грабли за Ваш счёт )
В статье было упоминание, что они даже с почтой и календарём не справились. А это уровень компетенции старательного ждуниор-админа. Что говорить об остальном…
Всего год? Молодцы. Быстро справились.
Сам наблюдал картину, как одна крупная контора в рамках страны переезжала с одной версии программы на другую три года. Смысл — отказаться от проприетарной и перейти на такую же по возможностями и интерфейсу, но своей разработки. Однако, там продумали репликацию между старой и новой версиями на уровне БД, но заставили по вечерам всех операторов сверять проводки, чтобы ничего случайно не потерялось.
В любом случае хочу Вам пожелать успеха в проекте. Продолжайте. Вы делаете полезное дело и пусть конкуренты не смущают — когда-то и про существование Линукс знала пара-тройка энтузиастов ;)
Т.к. это временной ряд, то при аварийном завершении приложения всегда можно подсмотреть время последней успешной вставки и недостающее подтянуть из внешнего «кеша». Помимо прочего, версия SQLite позволила реализовать consequtive disk access, а в момент старта приложения средствами SQLite производится проверка базы на консистентность pragma integrity_check. В общем, был реализован ряд мер, обеспечивающий и производительность, и надёжность для последовательной записи и обращений к временному ряду. Скорость выборок и вставки вне конкуренции с другими упомянутыми мной БД.
А вот и обещанная схема, она предельна проста. Одна отдельная БД с одной таблицей:
Абсолютно достаточно. Она, даже, избыточна по функционалу. Но это нельзя считать недостатком, т.к. на производительность приложения не влияет.
Потому, что быстрее просто не удалось найти. Проводился целый ряд исследований под конкретную потребность — хранение временных рядов (среди основных задач). Хочу особенно подчеркнуть, что каждая БД хороша под свои цели. При нагрузочном тестировании рассматривались BerkeleyDB и PostgreSQL в т.ч.
BDB отпала по двум причинам:
1. Она «не SQL» — там своя атмосфера. Дизайн API очень запутанный и странный.
2. Не имеет преимуществ по производительности в сравнении с SQLite.
Производительность PostgreSQL под требуемую задачу не идёт ни в какое сравнение с SQLite. SQLite доступен напрямую как сишная библиотека, которую можно статически собрать с приложением. К PostgreSQL доступ только по сокетам. PostgreSQL хороша для проектов с многопользовательской нагрузкой, с доступом к случайным фрагментам БД и сложными выборками. А для последовательного доступа к данным от имени одного приложения (как в случае с временными рядами) лучше, чем SQLite найти не удалось.
Возможно, где-то MySQL и является преимуществом, но не в научных задачах. По производительности она вообще не конкурент.
Насчёт кофеварок Вы погорячились ) SQLite полноценная БД со своими киллерфичами. Одна из самых быстрых и, кстати, среди прочего, умеет вложенные запросы, in-memory, и много того, чего не умеет MySQL, несмотря на свою «зрелость» и «корпоративную поддержку».
Пруфлинк в студию, пожалуйста!
Работаю в научной сфере с временными рядами без изысков и экзотики, используя банальную, хорошо настроенную SQLite. На 400 млн строк упомянутой у Вас просадки производительности для insert не наблюдается.
Вообще, хотелось бы увидеть сравнительные тесты разных БД с Вашей разработкой. SQLite в частности.
Clamav с начала времён страдал низкой угадываемостью вирусов. Не верите? Вложите eicar в zip и этот zip в другой zip. Всё! Клам даже не попробует проверить глубже одного вложения.
Вся остальная проприетарщина — софт для шпионажа. Не верите? А кто докажет что это не так без сорцов?
Итоги. Антивируса под Linux не было и нет. Контейнеризация или SELinux и… фух, оказывается антивирус и не нужен!
Где-то в этих комментариях уже упомянутый Приватбанк как раз соответствует.
Сам наблюдал картину, как одна крупная контора в рамках страны переезжала с одной версии программы на другую три года. Смысл — отказаться от проприетарной и перейти на такую же по возможностями и интерфейсу, но своей разработки. Однако, там продумали репликацию между старой и новой версиями на уровне БД, но заставили по вечерам всех операторов сверять проводки, чтобы ничего случайно не потерялось.