Комментарии 12
!!!
Он был сделан в почтовом ящике в конце 80-х.
Портирован на С на ПК в начале 90-х.
Язык команд подобен SQL.
Только команды русские:
ДТЬ — select
ИЗМ — update
ИСК — delete
ФКС — commit
и т.п.
И в нем была фишка автосоздания постоянных индексов для оптимизации запросов.
Как и в SQLite блокировка БД на изменение.
Транзакционность была на уровне буфера измененных страниц в памяти.
Эту БД решили делать, когда прочитали в конце 70-х в американском журнале статью IBM с описанием языка SQL.
Хипп, по сути, один из лучших программистов в мире в настоящем. Странно, что он не так популярен как некоторые другие. Но качество его кода просто запредельное.
Эскулайт пишет не один Ричард, посмотрите на сайте эскулайт раздел SQLite Developers. То есть Ричард сам пишет отличный код, делает отличные тесты, договаривается с коммерческими клиентами, обеспечивает поддержку всем пользователям, оперативно исправляет выявленные баги, собрал отличную команду, написал свою систему контроля версий,… А еще ему не мешают работать эффективные менеджеры :) В общем, чтобы в крупной компании такой человек-оркестр работал и ему не мешали — случается чрезвычайно редко.
закрывает все кейсы на одном компьютере/с одним пользователем
На самом деле, если задача позволяет все модификации базы выполнить в одном потоке, то эскулайт отлично работает на серверах, обслуживая уйму пользователей. Скажем, система навигации получает поток данных с миллиона машин, предобработанные данные пакетно пишет в эскулайт один раз в несколько секунд и всем водителям машин отображает текущую дорожную ситуацию — получаем все преимущества со сверхбыстрой выборкой данных, а еще можем легко ротировать минутные, часовые и суточные базы, которых эскулайт позволяет в одном соединении открыть и совместно использовать до 125 штук, см. https://www.sqlite.org/limits.html. Понятно, что множественные длинные пишущие транзакции в эту схему не укладываются, но вот в указанной задаче и многих других они просто не нужны.
А как же Redis? И автор тоже тиклер, заметьте. Если хотите крутой продукт от большой компании, то вот вам опен сорс и кроссплатформенный VTK Toolkit и основанный на нем ParaView. И в нем тоже раньше основной язык был тикль, потом переключились на питон. ParaView, в том числе, пилят и в Los Alamos National Laboratory, и если вы посмотрите, на каких кластерах ParaView способен распараллеливаться, то удивитесь, что он же отлично работает и на домашнем компьютере. Примеров подобных много, на самом деле, просто они обычно лежат за пределами общеизвестного софта.
Нормальная эволюция же. Неужели вы претендуете быть мудрее природы и сразу создавать шедевры?:) Вот хотя бы сравните обычные Btree индексы в эскулайт и FTS индексы. Если первые не поддерживают сжатие индексов и вообще одинарное дерево, то вторые — мультидерево со сжатием индексов и zlib сжатием. Лет 15 назад я выкладывал сравнительные тесты для таблиц в миллиарды записей — и FTS индекс отлично работал даже на таких масштабах данных, в отличие от Btree. И да, FTS писали в гугл, а не Ричард, насколько я знаю. В архивах рассылки эскулайт можно найти длиннющий тред, где автор FTS подробно объясняет мне, как там все устроено и работает:) Так что все же один человек большой продукт не в состоянии сам написать с нуля, и нужно еще уметь организовать высококлассную командную работу, что не менее сложно, чем создавать отличный код. Я до сих пор удивляюсь, как подробно команда эскулайт в рассылках отвечает на вопросы — и именно благодаря всем этим объяснениям они сумели комьюнити создать.
Кто-нибудь может объяснить, в чем удобство в отсутствии типов у колонок? В чем фишка? С первого взгляда выглядит скорее как минус, чем как плюс, но, может, я что-то не понимаю?
Попробуйте большой датасет из форматов типа CSV и подобных без строгой типизации загрузить в строго типизированную базу данных, например, в PostgreSQL. Вылезет уйма непредсказуемых ошибок типов, которые надо устранить до загрузки - то есть писать скрипты для построения гистограмм значений по столбцам для определения невалидных значений и прочее, что элементарно делается в SQL. Еще можно попытаться создать все столбцы текстового типа, потом вносить в них исправления и менять их тип, при ошибке снова проверять и исправлять. В результате окажется, что часть значений так сразу не поправить и тип многих полей останется текстовым, что потребует фильтрации невалидных значений и конвертацию остальных в нужный тип при каждом запросе… и так пока весь датасет не будет вычищен. Или можно загрузить датасет в SQLite с динамическими типами и сразу пользоваться всеми возможностями SQL для чистки данных и работы с ними. Поскольку SQLite создавался именно для замены разных самопальных форматов данных, такая возможность замечательно в том помогает.
Интервью с создателем SQLite (часть 2): Android 2005, хвала Кнуту, 100% тестовое покрытие, собственная CVS