Я пони. Тем не менее сделать это кмк просто. Конечно речь не идет о том, чтобы хранить всю историю. Но так как она уже хранится за некий период возмоность ее чтения ничем не навредит. Тем более как Вы справедливо заметили в том же редисе сообщения персистятся.
Пожелание: было бы здорово выделить библиотеку в отдельный репозиторий и навести порядок. Какая то полная каша с зависимостями, именованиями и бренчами центрифуг( Просто непонятно какие бренчи каких проектов клонировать в каой последовательности github.com/centrifugal/centrifuge/issues/8
Я завел ишью на github с конструктивным описанием функционала, думаю там удобнее будет обсудить целесообразность и возможность реализации метода для чтения истории непрочитанных сообщений: github.com/centrifugal/centrifugo/issues/228
Просто по факту — вы говорите что я могу реализовать это сбоку, но в данный момент это невозможно. Я могу это реализовать только параллельно центрифуге. Без возможности синхронизации с ней( А хотелось бы просто уметь читать историю сообщений из кеша центрифуги.
а почему вы не дали никаких методов в апи для построения на базе центрифуги чего то большего чем рилтайм транспорт доставки? Это принципиальная позиция или просто не было подобных запросов?
Вот смотрите, внутри центрифуги есть последний прочитанный уид в разрезе канал/клиент, как я понимаю
— но вы не дали метода его считать
— вы его не персистите для разрывов пока клиент зашел в метро как я понял, например
— вы не дали ни метода считать историю начиная с непрочитанного сообщения, по партициям/страницам, ни количества непрочитанных сообщений
Весь это функционал как бы есть (для кратковременных дисконектов, кстати насколько кратковременных? Секунда, сутки, это как то параметризируется?), но в апи — скрыт
Почему так? Это просто как то очень странно. Может быть я могу как то помочь реализовать это или описать тз или еще как то. Или вам это неинтересно?
Не смог понять функционал по описанию(
Допустим есть канал, правильно ли я понял:
— если емкость канала равна 50 сообщениям, в канале будут храниться 50 последних сообщений, упорядоченных по времени
— хранится ли где ть uid последнего прочитанного сообщения подписчиком, можно ли его получить и есть ли возможность считать unread count
— Как помечать сообщения как прочитанные на клиенте, есть ли какой то апи метод для этого
— Хранится ли эта инфа на сервере или отдается на откуп клиенту/бекенду
По описанию, понятно что есть вебсокеты для рилтайм режима и события/уведомления о подключении/отключении и новом сообщении. Но совершенно не понял что происходит между сессиями и какие возможности дает библиотека. Простите если глупые вопросы.
думал об этом, если честно — тупо не получилось транзакции привернуть. Вроде бы не самый сложный функционал, но когда полез в него — все оказалось сложнее
Все верно прям на 100%. Полный хардкор. Гораздо проще написать чтоть типа gorm, unique и не париться)
Сортировка есть всегда и для всех ключей, но только бинарная. Допустим, если нужна корректная целочисленная сортировка — необходимо конвертировать в bigendian:
```
for i := 0; i < 40; i++ {
id := make([]byte, 4)
binary.BigEndian.PutUint32(id, uint32(i))
}
```
В примерах и тестах много примеров
При извлечении указывается порядок:
```
//open Db and read tags by prefix 2:* in ascending order
tagsKeys, _ := slowpoke.Keys(tags, []byte(«2:*»), 0, 0, true)
for _, v := range tagsKeys {
fmt.Print(string(v) + ", ")
}
```
Следовательно если текстовое поле, например — можно извлечь все ключи начинающиеся с префикс* — но надо класть приведенными к нижнему регистру, например
Если от этого «бомбит» — лучше взять БД в которой проверки реализованы на уровне БД. Но придется забыть о скорости и гибкости.
А пример нужен затем — зачем вообще нужны примеры. Дать азы. Реальный медиум — будет слишком сложен для примера новичку, он просто запутается в коде. Поэтому и пишут такие дамми примеры для обучения.
Если неконсистентность в том, что потратится единица счетчика, то да
Но вообще я не рекомендую смотреть на примеры серии realworld.io, там очень до фига тупо за рамками здравого смысла. Практически все написано на отвали, чуваком который учит как писать, а не пишет. Начиная с апи. Это примеры. В реальной жизни я не буду запускать приложение на бекенде, делающее несколько запросов к БД на каждом запросе. Они тупо тупые. Если вы хотите боевой клон хабра, который «полетит» в reallife — я сейчас как раз пилю такой, на github.com/recoilme/tgram/tree/tgram
возможно берется картинка из кеша
там есть параметры управления кешом, и довольно гибкие, я бы попробовал включить для мелких мемори кеш, для крупных дисккеш, чтобы разделить кеши, но не уверен что дело в этом. сложно понять по описанию что происходит github.com/recoilme/malevich#advansed-usage
Полностью выкинута реалиционная база данных и написан бэкенд. С индексами, many-to-many отношениями и прочим. Просто как демонстрация того, что на slowpoke можно написать что угодно.
Спасибо за статью, прочел огромным с удовольствием, хоть и не совсем согласен. Ряд категоричных утверждений например про: times series… под капотом сидит Postgres. Ну фиг с ним. Или вот, например, про Redis:
Мы видим продукты, которые стали заложниками своей изначальной простоты, и они будут отваливаться, потихонечку уходить в небытие.
Тут меня прям бомбануло, простите. Давайте на примере Тарантул. Я слышал что тарантул раньше использовал sophiadb. Это довольно простой движок по сравнению с текущим как я понимаю. Два года назад на тестовом стенде тарантул за неделю успел как потерять данные при записи (тут в драйвере скорее всего была ошибка, не стал разбираться), показал намного худшую производительность (точных цифр не помню, но прям со свистом, раз в 10 на записи и в пару раз вроде на чтение vs SophiaDb) И наконец развалиться без какой либо возможности восстановления. Плюс отсутствие возможности юзать как апликейшен сервер из-за лимитов луа по памяти, и получился полный проигрыш по всем фронтам. Вроде бы движок мощнее, а смысл? Мы вынуждены были написать свой сервер на sophiadb и за два года, не возникло ни одной проблемы на нем, хотя и нагрузка выше, и падения серверов пережила база. Хотя казалось бы, в нем нет и половины фич тарантула. И вот если с первой частью статьи я почти везде согласен, то чем дальше — тем страшнее. Не превратитесь в Кассандру, Тарантул, в погоне за фичами. ps: выбираем жене машину — хочет — чтобы она была — быстрая, большая, проходимая, и камера и парктроники, и спереди и сзади и чтоб пищала когда сбоку в мертвой зоне и чтоб не хенде всякие и не дороже хенде и не б/у конечно. Так и клиенты — они много чего хотят от субд, пока не поймут, что иногда лучше меньше
После падения одной из год в кассандре, она отключается, и запросы, которые шли на данную году, перераспределяются на оставшиеся ноды. Падает следующая года и так, пока нод не останется. Как карточный домик она у нас складывалась, когда например падал самолёт, и трафик с подключены систем удваивался / утраивался.
В slowpoke нет NoSync, но есть пакетная запись, sets — с одним sync на пакет, он быстрее:
//macbook 2017 slowpoke vs boltdb
//The 100 Set took 19.440075ms to run./19.272079ms
//The 100 Sets took 1.139579ms to run./?
Это тесты на ssd — sync занимает около 1 ms. Это оч медленно (примерно 99% времени от set уходит на sync) На «шпинделе» — еще медленней раз в 100 или даже 1000. Секунда запросто уйдет — и с размером базы это не связано никак.
Вобщем можно юзать sets для быстрой вставки, но есть риск потерять весь пакет при креше.
Ну, slowpoke делает sync (fsync) на каждую операцию записи, не отложенный, по таймеру как сейчас стало модно, и не перед закрытием, например, а честный sync на каждый set/sets. Это самый дорогой и надежный способ синхронизации. Но конечно и он не дает 100% гарантии: danluu.com/file-consistency
До тех пор, пока Вы работаете с базой через интерфейс slowpoke — это безопасно. Но нельзя менять что то в файле напрямую, или к примеру запустить другую слоупоке, в другом процессе и натравить на тот же файл. Если я правильно понял задачу — Вам нужен сервер над slowpoke. Например, github.com/recoilme/okdb
Сервер будет обеспечивать доступ к базе из различных процессов, код будет чуть сложнее:
var conn *grpc.ClientConn
var err error
var f = "db/1.db"
conn, err = grpc.Dial(":7777", grpc.WithInsecure())
if err != nil {
log.Fatalf("did not connect: %s", err)
}
defer conn.Close()
c := api.NewOkdbClient(conn)
// Set
_, err = c.Set(context.Background(), &api.CmdSet{File: f, Key: []byte("1"), Val: []byte("1")})
// Get
b, err := c.Get(context.Background(), &api.CmdGet{File: f, Key: []byte("1")})
}
Метод сортировки в гоу, несмотря на название функции quickSort_func, под капотом содержит и сортировку вставкой, что должно привести к очень быстрой вставке новых ключей в отсортированный массив. И при Set — не вызывается (хотя такая идея была).
К моему стыду внедрена в продакшен она относительно недавно и опыта эксплуатации на миллиардах записей пока банально нет. Максимальный размер базы — несколько гигабайт. Надеюсь в ближайшее время перевести на нее более крупный проект, для которого первоначально и писал, но там нужна не встроенная база, а сразу grpc-сервер, который пока не закончен(
Это во многом справедливое замечание, спасибо. Метод Keys может быть написан получше. Но тесты показали что перестроение/хранение отсортированного дерева ключей (LLRB BTree) тоже не бесплатно. Версия на деревьях сохранилась в истории если интересно (https://github.com/recoilme/slowpoke/blob/ver.0.2/slowpoke.go) Просто в какой то момент я устал дебажить откуда и почему почему в дереве появился фантом( А если по скорости примерно тоже самое, зачем за него платить?
Пожелание: было бы здорово выделить библиотеку в отдельный репозиторий и навести порядок. Какая то полная каша с зависимостями, именованиями и бренчами центрифуг( Просто непонятно какие бренчи каких проектов клонировать в каой последовательности github.com/centrifugal/centrifuge/issues/8
Просто по факту — вы говорите что я могу реализовать это сбоку, но в данный момент это невозможно. Я могу это реализовать только параллельно центрифуге. Без возможности синхронизации с ней( А хотелось бы просто уметь читать историю сообщений из кеша центрифуги.
Вот смотрите, внутри центрифуги есть последний прочитанный уид в разрезе канал/клиент, как я понимаю
— но вы не дали метода его считать
— вы его не персистите для разрывов пока клиент зашел в метро как я понял, например
— вы не дали ни метода считать историю начиная с непрочитанного сообщения, по партициям/страницам, ни количества непрочитанных сообщений
Весь это функционал как бы есть (для кратковременных дисконектов, кстати насколько кратковременных? Секунда, сутки, это как то параметризируется?), но в апи — скрыт
Почему так? Это просто как то очень странно. Может быть я могу как то помочь реализовать это или описать тз или еще как то. Или вам это неинтересно?
Допустим есть канал, правильно ли я понял:
— если емкость канала равна 50 сообщениям, в канале будут храниться 50 последних сообщений, упорядоченных по времени
— хранится ли где ть uid последнего прочитанного сообщения подписчиком, можно ли его получить и есть ли возможность считать unread count
— Как помечать сообщения как прочитанные на клиенте, есть ли какой то апи метод для этого
— Хранится ли эта инфа на сервере или отдается на откуп клиенту/бекенду
По описанию, понятно что есть вебсокеты для рилтайм режима и события/уведомления о подключении/отключении и новом сообщении. Но совершенно не понял что происходит между сессиями и какие возможности дает библиотека. Простите если глупые вопросы.
Сортировка есть всегда и для всех ключей, но только бинарная. Допустим, если нужна корректная целочисленная сортировка — необходимо конвертировать в bigendian:
```
for i := 0; i < 40; i++ {
id := make([]byte, 4)
binary.BigEndian.PutUint32(id, uint32(i))
}
```
В примерах и тестах много примеров
При извлечении указывается порядок:
```
//open Db and read tags by prefix 2:* in ascending order
tagsKeys, _ := slowpoke.Keys(tags, []byte(«2:*»), 0, 0, true)
for _, v := range tagsKeys {
fmt.Print(string(v) + ", ")
}
```
Следовательно если текстовое поле, например — можно извлечь все ключи начинающиеся с префикс* — но надо класть приведенными к нижнему регистру, например
Если от этого «бомбит» — лучше взять БД в которой проверки реализованы на уровне БД. Но придется забыть о скорости и гибкости.
А пример нужен затем — зачем вообще нужны примеры. Дать азы. Реальный медиум — будет слишком сложен для примера новичку, он просто запутается в коде. Поэтому и пишут такие дамми примеры для обучения.
Но вообще я не рекомендую смотреть на примеры серии realworld.io, там очень до фига тупо за рамками здравого смысла. Практически все написано на отвали, чуваком который учит как писать, а не пишет. Начиная с апи. Это примеры. В реальной жизни я не буду запускать приложение на бекенде, делающее несколько запросов к БД на каждом запросе. Они тупо тупые. Если вы хотите боевой клон хабра, который «полетит» в reallife — я сейчас как раз пилю такой, на github.com/recoilme/tgram/tree/tgram
там есть параметры управления кешом, и довольно гибкие, я бы попробовал включить для мелких мемори кеш, для крупных дисккеш, чтобы разделить кеши, но не уверен что дело в этом. сложно понять по описанию что происходит
github.com/recoilme/malevich#advansed-usage
github.com/recoilme/golang-gin-realworld-example-app
Полностью выкинута реалиционная база данных и написан бэкенд. С индексами, many-to-many отношениями и прочим. Просто как демонстрация того, что на slowpoke можно написать что угодно.
Тут меня прям бомбануло, простите. Давайте на примере Тарантул. Я слышал что тарантул раньше использовал sophiadb. Это довольно простой движок по сравнению с текущим как я понимаю. Два года назад на тестовом стенде тарантул за неделю успел как потерять данные при записи (тут в драйвере скорее всего была ошибка, не стал разбираться), показал намного худшую производительность (точных цифр не помню, но прям со свистом, раз в 10 на записи и в пару раз вроде на чтение vs SophiaDb) И наконец развалиться без какой либо возможности восстановления. Плюс отсутствие возможности юзать как апликейшен сервер из-за лимитов луа по памяти, и получился полный проигрыш по всем фронтам. Вроде бы движок мощнее, а смысл? Мы вынуждены были написать свой сервер на sophiadb и за два года, не возникло ни одной проблемы на нем, хотя и нагрузка выше, и падения серверов пережила база. Хотя казалось бы, в нем нет и половины фич тарантула. И вот если с первой частью статьи я почти везде согласен, то чем дальше — тем страшнее. Не превратитесь в Кассандру, Тарантул, в погоне за фичами. ps: выбираем жене машину — хочет — чтобы она была — быстрая, большая, проходимая, и камера и парктроники, и спереди и сзади и чтоб пищала когда сбоку в мертвой зоне и чтоб не хенде всякие и не дороже хенде и не б/у конечно. Так и клиенты — они много чего хотят от субд, пока не поймут, что иногда лучше меньше
После падения одной из год в кассандре, она отключается, и запросы, которые шли на данную году, перераспределяются на оставшиеся ноды. Падает следующая года и так, пока нод не останется. Как карточный домик она у нас складывалась, когда например падал самолёт, и трафик с подключены систем удваивался / утраивался.
Там вроде boltdb внутри — github.com/NebulousLabs/Sia/blob/master/persist/boltdb.go
У болта есть режим DB.NoSync, он, естественно опасный — github.com/boltdb/bolt/issues/612
Бэкапы, реплики.
В slowpoke нет NoSync, но есть пакетная запись, sets — с одним sync на пакет, он быстрее:
//macbook 2017 slowpoke vs boltdb
//The 100 Set took 19.440075ms to run./19.272079ms
//The 100 Sets took 1.139579ms to run./?
Это тесты на ssd — sync занимает около 1 ms. Это оч медленно (примерно 99% времени от set уходит на sync) На «шпинделе» — еще медленней раз в 100 или даже 1000. Секунда запросто уйдет — и с размером базы это не связано никак.
Вобщем можно юзать sets для быстрой вставки, но есть риск потерять весь пакет при креше.
Сервер будет обеспечивать доступ к базе из различных процессов, код будет чуть сложнее: