И всё таки, почему мы начали разработку новой СУБД с нуля?
- Потому что на основе нашего опыта мы видим неиспользованный потенциал новейшего оборудования, который принесёт новые возможности пользователям.
- Потому что эксплуатировать старые архитектуры СУБД становится неэффективным и затратным как для разработчиков, так и для пользователей.
- Потому что мы хотим вывести на новый уровень безопасность и надежность продуктов, которые хранят в СУБД свои данные.
- Потому что наши разработчики не боятся решать, казалось бы непреодолимые задачи.
- Ну и потому что аналогов СУБД SoQoL ещё нет :)
А ещё на этот вопрос мы попросили ответить наших разработчиков. Вот их ответы:
- “Потому что мы знаем, как это сделать лучше, чем кто-либо уже сделал”.
- “Потому что к настоящему моменту все существующие массовые СУБД не обеспечивают производительности, потенциально возможной на современном "железе", без переписывания самой своей основы. Причём речь не о единицах-десятках процентов, а о многих сотнях процентов”.
- “Потому что это нужно людям, я в это верю). Потому что мы это умеем”.
- “Потому что у нас есть люди, обладающие нужными знаниями и умениями для решения этой задачи и у них есть идеи, позволяющие надеяться, что продукт будет успешным”.
И более развёрнутый ответ от коллеги:
“Рынок СУБД предъявляет всё большие требования к объёмам хранимых данных и к скорости их обработки. Благодаря этому на рынке появились неклассические и in-memory решения, позволяющие устранить ограничения классических проприетарных СУБД и СУБД с открытым исходным кодом.
Современные аппаратные платформы, особенно серверные, предполагают использование множества ядер и множества процессоров, больших объёмов памяти с неравномерным доступом (NUMA). Традиционная практика программирования классических СУБД, использующая блокирование доступа к общим ресурсам через блокировки, латчи и другие системные механизмы синхронизации, даёт неудовлетворительные показатели горизонтального масштабирования. В результате добавление новых ядер и процессоров не даёт кратного прироста производительности СУБД и приложений прикладного уровня. В научных статьях и современных практиках программирования всё чаще используются неблокирующие алгоритмы, дающие хорошие показатели масштабирования и полноценного использования аппаратных ресурсов. Но эти два разных подхода программирования предъявляют совершенно разные требования к построению архитектуры СУБД.
Поэтому нами принято решение о разработке СУБД "с нуля", где основной архитектурной особенностью, проходящей сквозь весь проект, будет использование неблокирующих подходов. При этом разрабатываемая нами СУБД должна быть классической реляционной СУБД, поддерживать стандарты SQL, поддерживать процедурный язык на основе JIT-компиляции.
Основная наша цель — получить классическую СУБД, производительность которой была бы сопоставима с высокопроизводительными неклассическими in-memory решениями. Также мы закладываем в новую архитектуру возможности горизонтального масштабирования и работу СУБД в кластерной конфигурации, а также в облаке. Это позволит нам выйти на рынок энтерпрайз решений, где доминируют зарубежные проприетарные СУБД”.
Мы можем и мы это сделаем! Ради наших пользователей!