История изменений

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

Да у нас и правда не сильно много.

Представьте std::unordered_map<PrimaryKey, Row> data;, который на старте целиком грузится в память и иногда сбрасывается на диск в fork() и прикрученный к этому делу сетевой интерфейс типа google protobuf и вот будет наша система. Никаких там блокировок, потому что один поток, никаких транзакций и хитрого вида запросов. Этакий чуть усложнённый ECHO-сервер. Ну или можно представить себе std::vector<Row> data; отсортированный по какому-то полю в этом Row, данные в котором ищутся бинпоиском. Или, допустим, в памяти лежит каждый 1024-й Row, а промежуточные поднимаются с диска по мере надобности - этакое 2-этажное фиксированное вырожденное «B+-Tree курильщика», позволяющее иметь максимум 1 доступ к диску в любом случае. Поднятые с диска блоки лежат в LRU на фиксированное их число. Тупо охренеть как, но нормальное B+-tree будет эффективнее на ноль процентов. А новые данные вставляем в какой-то in-memory хеш-таблиц. При поиске проверяем сначала in-memory, потом «дисковый». Получается некий такой LSM. Кончилось ОЗУ под in-memory - смёржили в fork()-е с дисковой частью, перезапустились, живём снова.

Теперь если представить, что все упомянутые тут сущности чуть-чуть оптимизированы в каком-то плане или переписаны на свои не сильно более сложные структуры данных (за годы существования системы), минимизирующие оверхед или позволяющие хранить часть данных на диске (курс «структуры данных во внешней памяти Максима Бабенко»), вы и получите нашу систему. Тут всё ещё не будет никаких транзакций, никакой многопоточности и никакого автоматического решардирования с блек джеком и шлюхами, всё ещё очень просто и тупо. Там реально работы любому увлечённому программисту на месяц по вечерам.

Внутренности SQLite в сравнении с этим кажутся космолётом. Там только код разбора SQL (которого у нас нет) и превращения его в какой-то там план выполнения запроса или просто в AST дерево будет сложнее чем всё что у нас написано)

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

Да у нас и правда не сильно много.

Представьте std::unordered_map<PrimaryKey, Row> data;, который на старте целиком грузится в память и иногда сбрасывается на диск в fork() и прикрученный к этому делу сетевой интерфейс типа google protobuf и вот будет наша система. Никаких там блокировок, потому что один поток, никаких транзакций и хитрого вида запросов. Этакий чуть усложнённый ECHO-сервер. Ну или можно представить себе std::vector<Row> data; отсортированный по какому-то полю в этом Row, данные в котором ищутся бинпоиском. Или, допустим, в памяти лежит каждый 1024-й Row, а промежуточные поднимаются с диска по мере надобности - этакое 2-этажное фиксированное вырожденное «B+-Tree курильщика», позволяющее иметь максимум 1 доступ к диску в любом случае. Поднятые с диска блоки лежат в LRU на фиксированное их число. Тупо охренеть как, но нормальное B+-tree будет эффективнее на ноль процентов. А новые данные вставляем в какой-то in-memory хеш-таблиц. При поиске проверяем сначала in-memory, потом «дисковый». Получается некий такой LSM. Кончилось ОЗУ под in-memory - смёржили в fork()-е с дисковой частью, перезапустились, живём снова.

Теперь если представить, что все упомянутые тут сущности чуть-чуть оптимизированы в каком-то плане или переписаны на свои не сильно более сложные структуры данных (за годы существования системы), минимизирующие оверхед или позволяющие хранить часть данных на диске (курс «структуры данных во внешней памяти Максима Бабенко»), вы и получите нашу систему. Тут всё ещё не будет никаких транзакций, никакой многопоточности и никакого автоматического решардирования с блек джеком и шлюхами, всё ещё очень просто и тупо. Там реально работы любому увлечённому программисту на месяц по вечерам.

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

Да у нас и правда не сильно много.

Представьте std::unordered_map<PrimaryKey, Row> data;, который на старте целиком грузится в память и иногда сбрасывается на диск в fork() и прикрученный к этому делу сетевой интерфейс типа google protobuf и вот будет наша система. Никаких там блокировок, потому что один поток, никаких транзакций и хитрого вида запросов. Этакий чуть усложнённый ECHO-сервер. Ну или можно представить себе std::vector<Row> data; отсортированный по какому-то полю в этом Row, данные в котором ищутся бинпоиском. Или, допустим, в памяти лежит каждый 1024-й Row, а промежуточные поднимаются с диска по мере надобности - этакое 2-этажное фиксированное вырожденное «B+-Tree курильщика», позволяющее иметь максимум 1 доступ к диску в любом случае. Тупо охренеть как, но нормальное B+-tree будет эффективнее на ноль процентов. А новые данные вставляем в какой-то in-memory хеш-таблиц. При поиске проверяем сначала in-memory, потом «дисковый». Получается некий такой LSM.

Теперь если представить что все упомянутые тут сущности чуть-чуть оптимизированы в каком-то плане или переписаны на свои не сильно более сложные структуры данных (за годы существования системы), минимизирующие оверхед или позволяющие хранить часть данных на диске (курс «структуры данных во внешней памяти Максима Бабенко»), вы и получите нашу систему. Там реально работы любому увлечённому программисту на месяц по вечерам.

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

Да у нас и правда не сильно много.

Представьте std::unordered_map<PrimaryKey, Row> data, который на старте целиком грузится в память и иногда сбрасывается на диск в fork() и прикрученный к этому делу сетевой интерфейс типа google protobuf и вот будет наша система. Никаких там блокировок, потому что один поток, никаких транзакций и хитрого вида запросов. Этакий чуть усложнённый ECHO-сервер.

Теперь если представить что все упомянутые тут сущности чуть-чуть оптимизированы в каком-то плане или переписаны на свои не сильно более сложные структуры данных, минимизирующие оверхед или позволяющие хранить часть данных на диске (курс «структуры данных во внешней памяти Максима Бабенко»), вы и получите нашу систему. Там реально работы любому увлечённому программисту на месяц по вечерам. Ну да с багами, ну и хер с ними.

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

Да у нас и правда не сильно много.

Представьте std::unordered_map<PrimaryKey, Row> data, который на старте целиком грузится в память и иногда сбрасывается на диск в fork() и прикрученный к этому делу сетевой интерфейс типа google protobuf и вот будет наша система.

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