(
бля лол
Size: a a a
2020 May 13
I
браузер изобрели
Ну вот кстати я уже несколько месяцев говорю:
- Сделайте бинарник, который поднимет локальный сервер и откроет дефолтный браузер.
- а ui верстайте на web-components / гоняя дифы через web-socket
- на ocaml такой бинарь занимает 1.2 MB (после upx)
- Сделайте бинарник, который поднимет локальный сервер и откроет дефолтный браузер.
- а ui верстайте на web-components / гоняя дифы через web-socket
- на ocaml такой бинарь занимает 1.2 MB (после upx)
AK
Ну вот кстати я уже несколько месяцев говорю:
- Сделайте бинарник, который поднимет локальный сервер и откроет дефолтный браузер.
- а ui верстайте на web-components / гоняя дифы через web-socket
- на ocaml такой бинарь занимает 1.2 MB (после upx)
- Сделайте бинарник, который поднимет локальный сервер и откроет дефолтный браузер.
- а ui верстайте на web-components / гоняя дифы через web-socket
- на ocaml такой бинарь занимает 1.2 MB (после upx)
так идея не нова, но чому-то не популярна, различные админки и тулинг так работает. последнее что помню, например, neo4j - поднимает сервер, пускает браузре там админка до бд. про то как это там свёрстано вообще хз
I
===
имутабельную key-value базу как раз сделать проще всего, если
- у каждой записи есть версия
- добавление/удаление всегда создает новую запись
а чтение делается условным
имутабельную key-value базу как раз сделать проще всего, если
- у каждой записи есть версия
- добавление/удаление всегда создает новую запись
а чтение делается условным
SELECT * FROM ?
WHERE version < ?
ORDER BY version
GROUP BY key
Я кстати допер как делать функциональную бд.
- Все изменения стора делаем отдельными событиями
- Пишем два редьсера
-- Один редьюсит локальный стор в памяти (1)
-- Второй асинхронно редьюсит те же события в хранилище на диск (2) (к примеру sqlite)
- все чтения (query) делаются из стора в памяти (1)
- при старте восстанавливаем состояние в памяти (1) по данным с диска (2)
- Все изменения стора делаем отдельными событиями
- Пишем два редьсера
-- Один редьюсит локальный стор в памяти (1)
-- Второй асинхронно редьюсит те же события в хранилище на диск (2) (к примеру sqlite)
- все чтения (query) делаются из стора в памяти (1)
- при старте восстанавливаем состояние в памяти (1) по данным с диска (2)
I
Это еще хорошо ложится на TEA подписки.
Правда там не решена проблема миграций и большого кол-ва данных (но иногда можно забить).
Правда там не решена проблема миграций и большого кол-ва данных (но иногда можно забить).
AK
Я кстати допер как делать функциональную бд.
- Все изменения стора делаем отдельными событиями
- Пишем два редьсера
-- Один редьюсит локальный стор в памяти (1)
-- Второй асинхронно редьюсит те же события в хранилище на диск (2) (к примеру sqlite)
- все чтения (query) делаются из стора в памяти (1)
- при старте восстанавливаем состояние в памяти (1) по данным с диска (2)
- Все изменения стора делаем отдельными событиями
- Пишем два редьсера
-- Один редьюсит локальный стор в памяти (1)
-- Второй асинхронно редьюсит те же события в хранилище на диск (2) (к примеру sqlite)
- все чтения (query) делаются из стора в памяти (1)
- при старте восстанавливаем состояние в памяти (1) по данным с диска (2)
а если они разойдутся? в память сохранишь, а на диск не получилось по каким-то причнам
I
ну пиздец будет конечно (но считаем что это не возможно)
QH
Я кстати допер как делать функциональную бд.
- Все изменения стора делаем отдельными событиями
- Пишем два редьсера
-- Один редьюсит локальный стор в памяти (1)
-- Второй асинхронно редьюсит те же события в хранилище на диск (2) (к примеру sqlite)
- все чтения (query) делаются из стора в памяти (1)
- при старте восстанавливаем состояние в памяти (1) по данным с диска (2)
- Все изменения стора делаем отдельными событиями
- Пишем два редьсера
-- Один редьюсит локальный стор в памяти (1)
-- Второй асинхронно редьюсит те же события в хранилище на диск (2) (к примеру sqlite)
- все чтения (query) делаются из стора в памяти (1)
- при старте восстанавливаем состояние в памяти (1) по данным с диска (2)
троллейбус_из_буханки.жпг
I
не сказал бы,
то же "Все изменения стора делаем отдельными событиями" это классика event-soursing
и тут своим компромисы - из плюсов что вся логика локальная и тестируема, при этом не сильно проседая по перформансу
то же "Все изменения стора делаем отдельными событиями" это классика event-soursing
и тут своим компромисы - из плюсов что вся логика локальная и тестируема, при этом не сильно проседая по перформансу
(
бля, просто ебани каппу в один дистрибутив
(
вместо кафки+стрим+редис просто одна твоя бд
(
у тебя есть AOL ивентов, которые стримятся в лёгкое фаст-рид дерьмо (вроде редиса) и если последнее дропается, восстанавливаешь его из лога
AK
вместо кафки+стрим+редис просто одна твоя бд
есть компактная и минималистичная штука для стрима логов - nats-streaming, один бинарь, можно собрать под что угодно, хоть под арм на андрюхе
(
есть компактная и минималистичная штука для стрима логов - nats-streaming, один бинарь, можно собрать под что угодно, хоть под арм на андрюхе
справедливо
(
ну короче, нужна AOL хуйня, стриминг хуйня и семи-персистент хуйня
I
бля, просто ебани каппу в один дистрибутив
А как бороться с разрастанием лога?
(
А как бороться с разрастанием лога?
не бороться
(
или делать время от времени снапшоты семиперсистента и брать его за начальное состояние, а лог чистить
(
я как-то был на докладе в альфа-банке как раз про эту архитектуру, у них там лог чёт под петабайт уже выжрал