Pull to refresh

Comments 81

Типы данных для хранения дат — DATE, TIMESTAMP и DATETIME

А что с таймзонами?
Есть типы данных для их учёта? И как этот учёт реализован?

Есть возможность работы с таймзонами. Есть описание в документации.

Текущие типы TIMESTAMP/DATE работают в локальном времени.

Узнать дату с учётом установленного часового пояса можно с помощью функций CURRENT_TIMESTAMP, LOCALTIMESTAMP, CURRENT_DATE. Узнать установленный часовой пояс можно с помощью функций DBTIMEZONE, SESSIONTIMEZONE.

Есть возможность работы с таймзонами. Есть описание в документации.

По документации не похоже, что есть. Да, есть таймзона сервера, и есть таймзона сессии. В документации не сказано, что insert/update переведет сохраняемое значение из таймзоны сессии в таймзону сервера, а select выполнит обратное преобразование.

От предыдущих продуктов осталось только упоминание родительского имени. Кодовая база ничего не имеет общего с ними.

а что в основе (postgres, mysql) - неужели не форк чего-либо?

Да, это не форк чего-либо. СУБД полностью разработана специалистами нашей компании.

В статье указано, что разработано с нуля. Но как-то сомнительно. На это нужно потратить годы кодирования. Например, на написание Post Ingres -> Postgres, прародителя PostgreSQL ушло 8 лет. И то, писалось не с нуля, и с использованием предыдущих наработок.

Все верно, на разработку ушло больше 7 лет.

Добавим, что компания появилась еще в 1990 году как разработчик российских систем управления базами данных. Подробнее про историю компании писали в нашем телеграм канале https://t.me/soqol_dbms

Если у вас реально ушло всего семь лет и вы не обманываете насчет превосходства над Postgress в 10 раз при сопоставимых тестах  и сопоставимой функциональности (то есть у вас не кастомное решение когда к примеру в обход SQL движка дается указатель на B-tree), то ваш коллектив это самые гениальные разработчики и тестировщики про кого мне доводилось слышать.

Вот историческая запись про Linter RDBMS
https://web.archive.org/web/20080210041441/http://www.linter.jp/english/
Лично я сталкивался с Линтер до 2000го года. Т.е. если ядро не переписали с нуля, а использовали старое, то как минимум 20-ть лет СУБД есть.

В SoQoL кроме части названия ничего от того ЛИНТЕР нет.

И да, СУБД продуктам семейства ЛИНТЕР уже больше 30 лет.

Сейчас в СУБД SoQoL поддерживаются программные интерфейсы ODBC, JDBC и PHP.

Из документации:

Напомним, что в составе дистрибутива текущей версии SOQOL ODBC-драйвер
поставляется в виде файла soqol-jdbc-<номер_версии>.jar

А есть планы на размещение JDBC-драйверов в публичных Maven-репозиториях?

P.S.
Ну и у вас опечатка в документации - раздел про JDBC-драйвер, а в тексте пишут про ODBC-драйвер.

Да, есть в планах публикация драйверов.

Спасибо! Документацию поправим.

Для логин-сервера, у которого даже 10к уников нет - пойдет.

У вас сайт для левшей или арабов? У вам ссылки там "<Следующаяя> <Предыдущия>"

Почему-то в Google Blogger сделано так же

Архитектура SoQoL в работе с данными поддерживает от самого нижнего до самого верхнего уровня неблокирующий подход

А есть планы на поддержку неблокирующей спецификации R2DBC?
Это из мира Java, альтернатива блокирующему JDBC.

Планируем в этом году реализовать.

Какой стандарт SQL уже поддерживает в каком-либо виде?

Лучшее что я нашёл в документации по этому поводу:

Целевой стандарт языка SQL: Система разработана с опорой на стандарт ANSI SQL:2016

Но такое описание не гарантирует собственно реализацию ANSI SQL:2016, так как реализована может быть только часть этого стандарта или вовсе что-то только отдалённо на него похожее.

Понятно что целиком никто стандарт не реализует, но одно дело отсутствие хронологии, другое дело CTE, рекурсивных запросов, оконных функции, XML или JSON.

Про CTE в документации есть параграф:

Common Table Expressions (CTE) — это именованный временный результирующий набор, который существует в рамках одного оператора и на который можно ссылаться в последующих запросах в рамках этого оператора, возможно, несколько раз.
Более подробное описание будет при ближайшем обновлении документа.

Рекурсивность упоминается рядом с CTE:

RECURSIVE WITH PUMP
Получение очередной записи из результатов WITH в рамках исполнения WITH с рекурсией.

Про оконные функции там ничего нет - перечислены только скалярные и агрегатные.
Термины XML и JSON так же не встречаются.

В планах есть JSON, но как быстро реализуем - пока вопрос.

Можно говорить о частичной поддержке SQL:99. В дальнейшем ориентируемся на поддержку стандарта SQL:2016.

А какая часть стандарта SQL:99 реализована?
Ну или что не реализовано?

Пока мы смотрим на то, что нужно сделать, а не то, насколько и чего из указанного стандарта не реализовано. Задача интересная, но пока не имеет высокого приоритета.

А что сейчас есть из стандарта? триггеры, регулярки, коллекции?
Что планируется дальше? Поддержки XQuery, XML, JSON ?

Триггеров не видно, хотя хранимки есть.
Про планы на JSON уже ответили, но судя по этому ответу XML даже не в планах.
Про регулярки я в доке ничего не встрелил, как просто поиском, так и анализом доступных операторов сравнения.

У вас в блоге очень интересное сравнение, показывающее превосходство над Postgres в 10 (десять) раз. В чем подвох?

Простите, но слабо верится, что из ниоткуда (пусть и после 7 лет разработки в "тишине") вышел продукт, который текущие индустривальные стандарты уделывает просто в лет.

Вы забыли сконфигурировать постгрес и гоняли его на стандартной конфигурации для 128Mb RAM? :)

UPD: https://soqol.ru/blog/testiruem-soqol/

UPD2: Если посчитать, то 250000/мин это 4166/сек. Не знаю что конкретно там делалось, но я бОльшую производительность за запись (на чтение там сильно быстрее будет) получал про простом переносе данных на сервере во много раз слабее (8 CPU, 8 RAM, 500Gb БД). Что-то тут не сходится.

Ну не совсем в тишине, писали о разработках и на TAdviser и CNews. Сюда вот только дошли...

У нас в компании есть специалисты по PostgreSQL и не только. А результаты обсуждали в телеграм-канале, где присутствуют не только наши разработчики. Вот ссылка, там есть и про конфигурации.

Пока не будет или свободной, как PostgreSQL, или бесплатной Development версии, как у MS - не взлетит, так как остаётся котом в мешке.

Хорошо, что хоть тут не стали писать, что превосходят PostgreSQL по производительности в 5-10 раз. Когда я впервые такое заявление увидел, так сразу же потерял всякий интерес. Без ущерба ACID, даже 50% выигрыш в производительности - на грани фантастики.

Демо-версия бесплатна и без ограничений. Можно использовать в разработке.

Ну так дайте ссылку на контейнер с ней.

Есть два варианта ее получить:

1) заполняете форму на сайте и получаете ссылку;

2) в телеграм-канале есть ссылка в закрепленных сообщениях на канал, где публикуем все сборки https://t.me/soqol_dbms

Что мешает разместить ссылку здесь? Для бесплатной Development версии тут ей самое место.

Бросайте уже это дело "по запросу". У вас есть демо, но "я вам её не отдам". Кучу потенциальных потребителей теряете.

Ну даже у Оракла можно без проблем скачать энтерпрайз дистрибутивы как СУБД базы данных, так и ОС, у вас что за секретность такая, так вы “слона не продадите”, если цель не на госсубсидиях сидеть, а выйти на рынок то наоборот нужно как можно проще распространять дистрибутивы.

На сайте сделайте раздел с скачиваем для демонстрационной версии. А то создается впечатлении как о компании "Рога и копыта" с девизом "Деньги утром, а стулья вечером".

Есть два варианта получить демо-версию:

1) заполняете форму на сайте и получаете ссылку;

2) в телеграм-канале есть ссылка в закрепленных сообщениях на канал, где публикуем все сборки https://t.me/soqol_dbms

Вообще-то стали :)

https://soqol.ru/blog/testiruem-soqol/

Главный вопрос - зачем?

Чтобы достичь хотя бы уровня текущего развития налогов уйдет ещё десяток лет.

Второй (риторический) вопрос - какова экономика бд? Кому и для чего нужно тратить столько денег и как их можно отбить?

Есть несколько причин, почему мы стали разрабатывать новую СУБД:

  • на основе нашего опыта мы видим неиспользованный потенциал новейшего оборудования, который принесёт новые возможности пользователям;

  • эксплуатировать старые архитектуры СУБД становится неэффективным и затратным как для разработчиков, так и для пользователей;

  • мы хотим вывести на новый уровень безопасность и надежность продуктов, которые хранят в СУБД свои данные;

  • наши разработчики не боятся решать, казалось бы непреодолимые задачи;

  • ну и потому что аналогов СУБД SoQoL ещё нет :)

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

Это интересно. Опишите пожалуйста как архитектура отличается и почему текущие старые и неэффективные?

Встроенный язык хранимых процедур - это хорошо. Но что насчет внешних пользовательских функций (UDF)? Есть ли возможность писать? И если да, то на чëм?

Пользовательские функции будут немного позже

А одинэс то на этом может работать?

В основе отсутствуют «костыли» и «закладки» open-source 
продуктов

запланирована сертификация ФСТЭК, ФСБ, Министерства обороны

Ясно понятно

Пара вопросов:
1. графическая среда для работы с базой - какую лучше использовать?
2. расширение функционала - на каких языках можно писать UDFs, SPs, Triggers ?

  1. Какая вам удобна, например, DBeaver

  2. Для процедур есть собственный процедурный язык, похож на оракловый PL/SQL, триггеров нет, пользовательские функции будут немного позже.

Для процедур есть собственный процедурный язык, похож на оракловый PL/SQL, триггеров нет, пользовательские функции будут немного позже.

Для меня это ограничение:
1. Я не хотел бы учить новый язык для описания сложной логики в базе
2. Гораздо удобнее использовать существующий язык с возможность подключения готовых библиотек

здравствуйте, а что насчёт индексов? как работает сопоставление строк? в документации как-то момент упущен.

Индексы на основе B-Tree, строковые данные сопоставляются через collation. В документации есть описание.

нет, я имел ввиду - как устроено сопоставление? вы ответили - "сопоставляются через сопоставление" (шта?) и "в документации есть описание" (нет). мой вопрос, если более детально - насколько поддерживается CLDR, сколько уровней в ключе (отсюда - поддерживается ли регистронезависимость), есть-ли поддержка правил сортировки чисел в строках?

На данный момент реализовано два варианта коллейшна для UCA: регистрозависимый и независимый.

спасибо! вариантов для различных локалей нет? хотя.. в 99% дефолтных весов более чем достаточно :)

p.s. с удовольствием бы почитал, как у вас организована многопоточность, если можно.

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

Частично описано про многопоточность в документации в разделе "Архитектура" подраздел "3.2 Технологическая платформа".

Свежо предание, но веретия с трудом….

Прочитайте статью про то как SQLite тестировался. А у вас все из коробки ибер костылей и PostgreSQL уделываете как стоячего.

Прогоните тесты SQLite думаю свалится ваша базальные половине тестов.

В основе отсутствуют «костыли» и «закладки» open-source
продуктов

А можно поподробнее, о каких костылях и закладках идёт речь? Хотелось бы конкретные примеры и ссылки на участки кода в github/gitlab/git*.

Очень буду благодарен! А то мы используем OS решения с своей инфраструктуре и очень переживаем.

Мультимастер из коробки присутствует?

А триггеры и типы range (и индексы для работы с ними) планируются? JSON, как я понял, будет, но позже.

Да, планируются.

Добрый день,
В официальной документации встречается не только тип данных VARCHAR, но и VARCHAR2. Как получилось так, что при разработке СУБД с нуля за последние 7 лет появилась необходимость во втором типе данных для строковых значений? Из известных мне СУБД точно так же именованные типы данных встречаются в одной, той что начинается на Ora и заканчивается на cle.

У разработчиков той СУБД срок разработки с нуля, безусловно, превышает 7 лет, поэтому я вполне понимаю, откуда возникли исходные ограничения для VARCHAR, и почему пришлось сделать VARCHAR2, чтобы их обойти. Но зачем два синонима для СУБД, созданной уже после 2010 года?

И почему было решено использовать в качестве основного типа данных для целых чисел NUMERIC и его производные, точь-в-точь как у вышеупомянутой СУБД?

Никаких скрытых причин. Всего лишь для упрощения миграций.

VARCHAR2 — всего лишь синоним VARCHAR.

поставил

беру из постгрес

CREATE TABLE "ee3" (

"Id" INTEGER NOT NULL CONSTRAINT "PK_S3" PRIMARY KEY,

"WorksheetPrintName" varchar NULL,

"FirstInputColumn" INTEGER NOT NULL

);

QL Error [HY000]: Statement execute failed. // code:-25001// [ru.relex.soqol.jdbc.statement.SOQOLStatementImpl; [code:-25001, tag:0, text:"(2,33)ERROR: syntax error, unexpected NULL, expecting ("]; stmtId: 151;]

щито?

Замечательно, что появилась современная СУБД с российскими корнями. Помогите разобраться, на каких пользователей рассчитан SOQOL как продукт: гос. структуры, крупный бизнес и/или разработчики прикладного ПО общего назначения и любого масштаба?

Как и любая транзакционная реляционная СУБД, SoQoL не имеет ограничений в использовании. Это межотраслевое ПО, которое в первую очередь нацелено на использование в приложениях коммерческих предприятий и разработчиков тиражируемого прикладного ПО.

Для широкого применения не столь важна победа над другими СУБД по техническим характеристикам, как наличие коннекторов к популярным фреймворкам, подробная документация с примерами, активное сообщество, уверенность, что новая СУБД - это модно и круто. По этим компонентам работа ещё только предстоит, на мой взгляд. Да, и возможность скачать без ввода телефонного номера )

Так и сейчас можно скачать без ввода телефонного номера из ТГ. Вот прямая ссылка https://t.me/c/1808663110/55

про бекапы написано очень уж кратко и только холодный бекап описан с остановкой СУБД

вот сделал я бекап и хочу восстановить на какой-то конкретный момент времени

WAL вроде есть, значит можно накатить их на холодный бекап, какую-то их часть

но нет механизма выбрать этот момент

жаль...

Все верно про WAL. Работаем над этим.

Интересно как с архитектурой в новой системы, если нет блокировок то это может быть одно поточная система. Иначе нужны блокировки как минимум страниц БД. Если много поточная система то как она живет на NUMA архитектуре.

В документации есть раздел "Архитектурные аспекты".

В части 15.1 документации про резервное копирование: https://soqol.ru/dokumentatsiya/ написано, что перед резервным копированием, нужно остановить работу самой базы данных. Но как тогда делать резервное копирование на постоянной основе без простоя? Эта особенность явно не делает данную СУБД конкурентоспособной по отношению к другим известным СУБД, таким как MySQL, PostgreSQL, MS SQL, Oracle и др. Тем более что лицензия платная. Когда примерно планируется реализовать возможность резервного копирования на лету как всей базы данных, так и конкретной дельты-напр, последнего фрагмента журнала транзакций? Ещё бы реализовать возможность непрерывного резервного копирования с возможностью быстрого восстановления на каждый нужный момент времени как это уже реализовано в современных известных СУБД в том числе для реализации отказоустойчивых решений и для быстрой доступности.

Спасибо за предложение! Работаем над системой резервного копирования в данный момент.

Когда примерно будет готово?

Sign up to leave a comment.

Articles