Search
Write a publication
Pull to refresh
98
25
Соловьев Сергей @AshBlade

Бэкэнд разработчик, но для ПМ могу быть кем угодно

Send message

С конечной лицензией вопрос, честно говоря, сложным не был.

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

Из заимствований можно назвать только оптимизацию simple neighborhood. Но, во-первых, это известная оптимизация, которая используется многими СУБД (MySQL и YDB в их числе), а, во-вторых, использована только идея, но не конечная реализация (в MySQL и YDB simple neighborhood создается для всех простых гиперузлов, а в расширении он создается для каждого гиперузла, который создается в процессе работы). Поэтому коллизий лицензий быть не должно.

Тогда сжатие будет происходить для всего, даже метаданных (это раз) и над управлением сжатием у нас, по факту, власти не будет (это два).

Еще можно добавить, что strlen(NULL), вызывает SEGFAULT, хотя этого в мане не описано

Уххх. Это было 2 года назад. Уже и не вспомню большую часть про настройку.

Единственное что могу вспомнить - конфиг nginx зашивал в докер образ. Это да.

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

Алгоритм интересный, но я бы использовал MD5 вместо SHA - меньше вероятность коллизий

"Выделение нового участка файла", вместо "Выделение новых блоков памяти" в 1

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

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

  3. Да, но тут уже важен порядок этих операций.

  4. Встречается, но как уже писал, на это лучше не полагаться

  5. Какой алгоритм? Накопитель исправляет ошибки, а мы - только обнаруживаем

Не совсем. Да, может только увеличиться размер файла успеть, но:

  • Никто не гарантирует, что там будут 0 - скорее будет случайный мусор

  • Если 4Кб имеется ввиду сектор, то тут больше про атомарность и PSOW - записаться может только часть. Например, корректно инициализируется заголовок, но остальное будет мусором. Без чек-сумм тут не обойтись

  • Писать независимые порции данных - дозапись или перезапись? Перезапись может быть атомарной (в исследовании все были атомарны), но не гарантируется. Дозапись - уже вряд-ли атомарна

  • Дополнительно, необходимо понимать размер сектора - где-то это 512 байт, а где-то 4096. Причем, некоторые диски могут работать в эмулируемом режиме (512e), что затруднит работу

  • Ко всему прочему, в процессе хранения целостность может быть нарушена и без чек-сумм тут не обойтись (накопитель может не справиться с исправлением)

Спасибо за замечание, исправил.

Насчет NtFlushBuffersFileEx - в черновике оставил это замечание и забыл перепроверить: скорее всего где-то прочитал, но найти заново не смог. Удалил на всякий случай, чтобы не дезинформировать

Мне это тоже показалось странным, но потом пришел к выводу, что, в общем, это логично:

  1. База данных, как и пользовательский интерфейс, - это плохой внешний мир. Функциональщики такое называют side effect, даже оборачивают в монады (привет IO из haskell)

  2. Можно сделать логическое разграничение на 2 множества:

    • Веб, UI - это взаимодействие С нами

    • БД, внешние сервисы, устройства - это уже МЫ взаимодействуем

    И эти множества расположены близко друг к други на противоположных краях слоя, как бы вход и выход.

    Такое разграничение явно не проговаривалось, но лично я это так интерпретирую.

Вставлю свои 2 копейки

  1. restrict - единственное ключевое слово из C, которое не поддерживается в C++

  2. Есть заголовок <setjmp.h>, который (добавляет функции, возволяющие) позволяет делать нелокальные переходы. Т.е. можно вернуться вверх по стеку через несколько функций без явного return. В C++ она хоть есть, но если использовать, то можно забыть о всех деструкторах - они вызваны не будут.

Решения из жизни.

Первое. На каждый запрос открывается транзакция. Кто первый закоммитил - тот и будет смотреть. Поймали ConcurrencyException - говорим Васе, что в кино не пойдет.

Второе. Да, код не оптимален. Его основная задача не решение бизнес-задач, а существование в качестве примера. DBA не придет, можно спать спокойно.

Действительно, грубая ошибка.

Как по мне этот пример больше про 3-слойное приложение:

  1. Все модели наследуются от BaseModel, который нужен для правильной сериализации и работы с БД - и только для этого

  2. Модели анемичные. По факту, выполняют роль DTO

  3. На диаграмме бизнес-логика зависит от БД

  4. В данном классе должна быть заключена вся бизнес-логика приложения (BookBookService) - я увидел лишь простое делегирование вызовов, без какой либо бизнес-логики

Вывод - это 3 слойное приложение, которое называют чистой архитектурой

Можно и так было написать. Но без последних нулей проще понять, что работаем с полубайтами

Расстояние Хэмминга 2 - это же 2 ошибки, разве нет?

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

И второй вопрос - почему для разных расстояний разные полиномы? То есть, полином, ловящий 5 ошибок, может не поймать 2, так, что ли?

Как уже сказано выше - HD = 6, означает, что такой полином может отловить до 5 ошибок включительно

P.S. добавил это в статью, спасибо

постмодернпродакшн

Information

Rating
711-th
Location
Нижний Новгород, Нижегородская обл., Россия
Works in
Registered
Activity

Specialization

Backend Developer, Database Developer
Middle
PostgreSQL
Linux
C
System Programming
Database