Как стать автором
Обновить

Комментарии 31

Спасибо за статью. А можно ссылку на гитхаб?
Большое спасибо ;)
НЛО прилетело и опубликовало эту надпись здесь
Ну скорость, она да. Спасибо, что есть. 10к записей в секунду делало при летной погоде. На детальные бенчмарки времени не осталось, к сожалению.

Есть много мест, которые можно оптимизировать. Например, если отдебажить доступы к блокам, можно заметить, что много излишних чтений приходится на дескрипторы таблиц, тогда как можно было бы их закешировать.
НЛО прилетело и опубликовало эту надпись здесь
/select дает RowSet (выборку). Он ленивый (кроме MockRowSet, например, для мастер-таблицы /autism). Проходка по нему итератором достает из блоков по одной записи за раз. В памяти это никак специально не кешируется — и возможно, зря, но это уже другая история. В конце концов ещё есть кеш файла в операционной системе, и его размер равен 16 блокам.
Давайте аргументированно покритикую.

Очевидным аргументом против исключений является то, что разбрасываться ими дорого, а ловить — громоздко.

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

Ситуация ухудшается тем, что Python даже в версии 3.6 с Type Annotations, в отличие от той же Java, не позволяет указать типы исключений, которые могут вылететь из метода. Иначе говоря: глядя на сигнатуру метода, должно стать ясно, чего от него ожидать.

Добавление нового типа исключения в метод потребует изменения аннотации для всех других методов его вызывающих и далее вверх по цепочке вызовов. А вот компилятора, который будет следить, чтобы аннотированные исключения были обработаны, в Питоне нет. Так что польза от такой аннотации крайне сомнительна.

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

И заодно заполоняя код бесконечными проверками возвращённых ошибок.
t = tokens.next().and_then(Cast(Delete))
if not t: return IErr(t.err())

t = tokens.next().and_then(Cast(From))
if not t: return IErr(t.err().empty_to_incomplete())

t = tokens.next().and_then(Cast(Identifier))
if not t: return IErr(t.err().empty_to_incomplete())
table = t.ok()

t = WhereFromSQL.from_sql(tokens)
if not t: return IErr(t.err().empty_to_incomplete())
where = t.ok()

t = tokens.next().and_then(Cast(Drop))
if not t: return IErr(t.err().empty_to_incomplete())


Исключения объективно решают больше проблем и имеют меньше недостатков, чем возвраты ошибок. Вот хорошая статья на эту тему.

Можно у меня будет наконец статическая типизация в Python, ну пожаалуйста?

Надеюсь, это шутка. Если нет, то вы просто выбрали не тот инструмент. Взяли бы Go: и типизация, и возвращаемые ошибки — всё как вы хотите.

В общем, извините, код не понравился совершенно.
Взяли бы Go

И остались бы без возможности строить красивые абстракции совершенно. Тогда уж раст, тем более что Result из него заимствовали, а возврат ошибок там не выглядит громоздко.

По поводу инструмента мои 5 копеек:
Выбрали тот инструмент, которым умели пользоваться. Время было ограничено (как я понял), поэтому выбор был сделан верно, поскольку изучение нового инструмента с большой вероятностью не позволило бы решить задачу в срок. Решение удовлетворяет установленным критериям.

Это не избавляет от того, что для более «серьезных» задач, ну скажем миллиард записей — это работать не будет. И нужен будет уже другой инструмент. Да, не масштабируемо — так и не требовалось.
Выбрали тот инструмент, которым умели пользоваться. Время было ограничено (как я понял), поэтому выбор был сделан верно, поскольку изучение нового инструмента с большой вероятностью не позволило бы решить задачу в срок
Инструмент был строго задан техническим заданием ( ratijas, к сожалению, не расписал это в статье). Мы в университете не мешки ворочаем, о разных инструментах знаем и пользоваться умеем. А изучение нового инструмента на ходу, по моему опыту, в университете не является проблемой.
ну скажем миллиард записей
Обрабатывать будет долго, вероятно, но не развалится.
Как часто при типичной работе программы происходит выброс/ловля исключений?

Вы статью читали? У них даже EOF при чтении команд идёт как ошибка. За исключение в этом месте надо расстреливать через тумба-юмбу.
Я даже боюсь представить, что же надо делать за исключение при работе с каждым итератором.
Очень странная постановка задачи. СУБД на интерпретируемом языке? Серьёзно?

Учебная задача же, а не продукт для рынка. Задача, очевидно, была в разработке учебной СУБД для более глубокого осознания механизмов работы систем управления базами данных.

Были извращенцы которые key-value хранилище на php делали :)
А есть идеи и планы дальнейшего развития вашего проекта до чего то полезного на практике. А то тоже не раз меня посещала идея сделать свою субд правда на С++ но каждый раз я не мог найти ответа на вопросы ЗАЧЕМ и для КОГО?

Т.к. статья студенческая — выскажусь исходя из своего преподавательского опыта.


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


Причина раздражения очень проста — я уже всё это знаю и мне хочется быстрее выяснить что вы умеете и чему научились, а не рассматривать братуху-борцуху на мемичных картинках. По этой же причине длительное отступление про исключения совершенно излишне. Достаточно вскользь упомянуть. Если читающему\слушающему будет это интересно — он расспросит, не сомневайтесь. А то на ровном месте получили кучу вопросов про совершенно второстепенную в вашей задаче проблему.


Аналогично раздражают частые англицизмы и отсутствие единого стиля. Почему СУБД и КиБ, но AST и DDL? Очень много странных с т.з. русского языка конструкций, вроде "В команде нас только двое (не считая себя и мою персону)" и "С формальной частью закончили, перейдем к практической", ведь антагонистом практики является теория, а не формальность.


Пришлось заставлять себя читать статью, ведь буквально на первой странице:


Согласно ТЗ, требовалось создать

Очень плохое начало. Непонятно откудо взялось ТЗ — у читющих возникают вопросы https://habrahabr.ru/post/347274/#comment_10629794
https://habrahabr.ru/post/347274/#comment_10629754


выдерживает 100'000 записей

Что значит выдерживает? И подобное буквально в каждом абзаце. Я вижу что вы — молодцы и программируете (рамках курса, хе хе) на должном уровне. Но нужно тренироваться писать тексты и доносить мысль до слушателя. Это не просто.


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

Простите, но Ваша манера критики не очень уместна в публичном месте, будь Вы преподаватель или кто


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

И далее. Если Вы принимаете работу — тогда пожалучйста (и то не уверен). Лучше комментарии по делу


Аналогично раздражают частые англицизмы и отсутствие единого стиля. Почему СУБД и КиБ, но AST и DDL

СУБД — широко распространенное сокращение, DDL — не видел варианта на русском языке. Не вижу проблемы, т.к. это не квалификационная работа


В целом — не воспринимайте статью как реферат, иначе читать было бы невозможно

Простите, но Ваша манера критики не очень уместна в публичном месте, будь Вы преподаватель или кто

А мне нравится. Не вижу причин, почему у публичной статьи не может быть публичной критики. Я же исключительно про статью, а не про авторов которые, повторюсь, молодцы. Из текста видно что пишут студенты, причём трижды Иннополис вспоминают. И лучше я им здесь укажу на проблемы, чем на сдаче диплома член комиссии.


Может у автора спросим, что он думает про мои комментарии? А то мне кажется Вы защищаете того, кто в этом не нуждается.


DDL — не видел варианта на русском языке.

Язык описания данных, ЯОД.


Термин массово используется в русскоязычной литературе. Даже ГОСТ есть — "ГОСТ 20886-85 Организация данных в системе обработки данных. Термины и определения".

А мне нравится. Не вижу причин, почему у публичной статьи не может быть публичной критики.

Я про Вашу манеру, а не про критику. Критику хочется видеть конструктивную, без эмоций подобно Вашим

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

Пишут студенты.
Студенты учатся программировать.

А ещё студенты учатся писать статьи ->
Написание статей автором подразумевает чтение статей читателем->
Читатель читая эту статью будет раздражаться ->
Я, имея опыт преподаваня и чтения статей, указываю на причины подобного раздражения ->
Студенты учатся писать более грамотные статьи ->
Я молодец
когда вы показываете старшим товарищам что вы умеете

Печально, когда люди начинают причислять себя к старшим товарищам.
Иначе говоря: глядя на сигнатуру метода, должно стать ясно, чего от него ожидать.

В python это работает через doc string, в которых можно писать raises, который можно получить напимер, так: a.c1.__doc__. Внешние либы часто грешат игнорированием этого правила, но стандартная библиотека python его отлично придерживается.


Ну и да, исключения в python не настолько дорогие.

Конечно. Однако, как мы (в Иннополисе) уже поняли горьким опытом по языку Eiffel, документация не заменит сигнатуры, а сигнатуры — документацию.
Стоило произнести запретное слово — сразу молча минус. Вау!
А зачем в метаданных базы поле с количеством блоков и поле Records Count в заголовках таблицы?
В случае большой OLTP-нагрузки будет конкуренция за заголовок у множества процессов. Может, лучше без них обойтись? Стоит ли быстрый select count(*) того?
Это костыль. В проекте много что можно улучшить, благодаря курсу по СУБД, ОС и набору курсов по программированию мы прекрасно знаем как это сделать.
Но проект сделан Just For Fun в последние три учебных недели, когда кроме всего прочего надо было готовиться к экзаменам и вообще.
А кстати, count(*), как и функции вообще, пока что не поддерживаются. Есть вероятность, что силами студентов к лету допилим.
Достаточно познавательно! Рекомендую всем.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории