Соловьев Сергей @AshBlade
Бэкэнд разработчик, но для ПМ могу быть кем угодно
Information
- Rating
- 711-th
- Location
- Нижний Новгород, Нижегородская обл., Россия
- Works in
- Registered
- Activity
Specialization
Backend Developer, Database Developer
Middle
PostgreSQL
Linux
C
System Programming
Database
С конечной лицензией вопрос, честно говоря, сложным не был.
Одна из задач расширения - сделать его доступным для использования не только обычными людьми, но и компаниями, поэтому свою лицензию создавать не особо хороший вариант. Также, учитывая, что у PostgreSQL лицензия похожа на MIT, то выбор пал на последнего.
Из заимствований можно назвать только оптимизацию simple neighborhood. Но, во-первых, это известная оптимизация, которая используется многими СУБД (MySQL и YDB в их числе), а, во-вторых, использована только идея, но не конечная реализация (в MySQL и YDB simple neighborhood создается для всех простых гиперузлов, а в расширении он создается для каждого гиперузла, который создается в процессе работы). Поэтому коллизий лицензий быть не должно.
Добавил
Тогда сжатие будет происходить для всего, даже метаданных (это раз) и над управлением сжатием у нас, по факту, власти не будет (это два).
Еще можно добавить, что
strlen(NULL)
, вызывает SEGFAULT, хотя этого в мане не описаноУххх. Это было 2 года назад. Уже и не вспомню большую часть про настройку.
Единственное что могу вспомнить - конфиг nginx зашивал в докер образ. Это да.
Такие дипломы есть - называется сертификация. А высшее образование предполагает не только имение навыка тыкать на кнопочки, а общую эрудицию и широкий кругозор.
Алгоритм интересный, но я бы использовал MD5 вместо SHA - меньше вероятность коллизий
"Выделение нового участка файла", вместо "Выделение новых блоков памяти" в 1
Выделение новых блоков памяти - это не тоже самое что и выделение новой памяти. Здесь нельзя просто взять и занулить целую область. В ext режиме ordered сначала может обновиться длина, а что в выделенной области - неизвестно, т.к. предполагается что запись будет успешной.
Про накопители говорить не буду, но из предоставленной таблицы ясно что приложения не преполагают полную атомарность и PSOW. Поэтому их можно использовать в различной инфраструктуре и не покупать специальное оборудование
Да, но тут уже важен порядок этих операций.
Встречается, но как уже писал, на это лучше не полагаться
Какой алгоритм? Накопитель исправляет ошибки, а мы - только обнаруживаем
Не совсем. Да, может только увеличиться размер файла успеть, но:
Никто не гарантирует, что там будут 0 - скорее будет случайный мусор
Если 4Кб имеется ввиду сектор, то тут больше про атомарность и PSOW - записаться может только часть. Например, корректно инициализируется заголовок, но остальное будет мусором. Без чек-сумм тут не обойтись
Писать независимые порции данных - дозапись или перезапись? Перезапись может быть атомарной (в исследовании все были атомарны), но не гарантируется. Дозапись - уже вряд-ли атомарна
Дополнительно, необходимо понимать размер сектора - где-то это 512 байт, а где-то 4096. Причем, некоторые диски могут работать в эмулируемом режиме (512e), что затруднит работу
Ко всему прочему, в процессе хранения целостность может быть нарушена и без чек-сумм тут не обойтись (накопитель может не справиться с исправлением)
Спасибо за замечание, исправил.
Насчет
NtFlushBuffersFileEx
- в черновике оставил это замечание и забыл перепроверить: скорее всего где-то прочитал, но найти заново не смог. Удалил на всякий случай, чтобы не дезинформироватьМне это тоже показалось странным, но потом пришел к выводу, что, в общем, это логично:
База данных, как и пользовательский интерфейс, - это плохой внешний мир. Функциональщики такое называют side effect, даже оборачивают в монады (привет IO из haskell)
Можно сделать логическое разграничение на 2 множества:
Веб, UI - это взаимодействие С нами
БД, внешние сервисы, устройства - это уже МЫ взаимодействуем
И эти множества расположены близко друг к други на противоположных краях слоя, как бы вход и выход.
Такое разграничение явно не проговаривалось, но лично я это так интерпретирую.
Вставлю свои 2 копейки
restrict - единственное ключевое слово из C, которое не поддерживается в C++
Есть заголовок <setjmp.h>, который (добавляет функции, возволяющие) позволяет делать нелокальные переходы. Т.е. можно вернуться вверх по стеку через несколько функций без явного
return
. В C++ она хоть есть, но если использовать, то можно забыть о всех деструкторах - они вызваны не будут.Решения из жизни.
Первое. На каждый запрос открывается транзакция. Кто первый закоммитил - тот и будет смотреть. Поймали ConcurrencyException - говорим Васе, что в кино не пойдет.
Второе. Да, код не оптимален. Его основная задача не решение бизнес-задач, а существование в качестве примера. DBA не придет, можно спать спокойно.
Действительно, грубая ошибка.
Как по мне этот пример больше про 3-слойное приложение:
Все модели наследуются от BaseModel, который нужен для правильной сериализации и работы с БД - и только для этого
Модели анемичные. По факту, выполняют роль DTO
На диаграмме бизнес-логика зависит от БД
В данном классе должна быть заключена вся бизнес-логика приложения
(BookBookService) - я увидел лишь простое делегирование вызовов, без какой либо бизнес-логикиВывод - это 3 слойное приложение, которое называют чистой архитектурой
Можно и так было написать. Но без последних нулей проще понять, что работаем с полубайтами
Можете сами посмотреть
В данном случае, расстояние хэмминга - это количество изменений битов, начиная с которых может произойти коллизия и ошибки не будут заметны. На сколько понял, определялось эмпирически.
Как уже сказано выше - HD = 6, означает, что такой полином может отловить до 5 ошибок включительно
P.S. добавил это в статью, спасибо
пост
модернпродакшн