EN
Так можно сказать, что очередь за капустой - не очередь)) но она же очередь
Size: a a a
2020 November 25
PD
Так можно сказать, что очередь за капустой - не очередь)) но она же очередь
Почему? Порядок есть, FIFO есть - значит очередь )
EN
дык яж и не спорю, я про таблицу оппонирую)
VN
Так можно сказать, что очередь за капустой - не очередь)) но она же очередь
ну с натяжкой, и только в том случае что продают из под полы...
Более того если в силу экономии пространства есть 2 и более цепочек, людей, но к кассе они приходят в соответствии с тем как они зашли в магазин то тоже себе вполне...
Более того если в силу экономии пространства есть 2 и более цепочек, людей, но к кассе они приходят в соответствии с тем как они зашли в магазин то тоже себе вполне...
N
если эмулировать очередь таблицой, то она не будет быстро работать. Если на HDD, то можно будет порядка тысячи выжать, а больше не удастся. НА SSD можно наверное 10 K сделать
N
еще и не каждая база даст аналог SKIP LOCKED, а без него совсем будет медленно. Вот пришли 10 сессий с deque. как узнать какие залочены, а какие нет, если нет skip locked?
GK
дык яж и не спорю, я про таблицу оппонирую)
Речь об абстракции над таблицей
N
Эта абстракция будет нежизнеспособной. в базе нельзя например сделать условный 10 тыс активных сессий.
GK
Nikolay
Эта абстракция будет нежизнеспособной. в базе нельзя например сделать условный 10 тыс активных сессий.
Почему активных?
GK
Короче, и так понятно:
- база может быть нереляционной
- у баз ниже пропускная способность, чем у очередей и распределённых логов (pub sub)
- база может быть нереляционной
- у баз ниже пропускная способность, чем у очередей и распределённых логов (pub sub)
PD
Nikolay
еще и не каждая база даст аналог SKIP LOCKED, а без него совсем будет медленно. Вот пришли 10 сессий с deque. как узнать какие залочены, а какие нет, если нет skip locked?
Ну, я ровно про это и писал выше. Ну и 10K - тоже сложно на дешевом железе.
PD
Но если база типа FDB - то можно и сотню тысяч получить.
PD
На HDD, кстати, 1000 не получить, там где-то 300 IOPS, не больше.
VN
А можно вопррос, в каком случае нужна высокая производительность для долгоживущих сообщений, а для короткоживущих, может быть все-таки ин-мемори (возможно, с резервным копированием) будет удобней?
PD
V N
А можно вопррос, в каком случае нужна высокая производительность для долгоживущих сообщений, а для короткоживущих, может быть все-таки ин-мемори (возможно, с резервным копированием) будет удобней?
А не известно заранее, насколько конкретное сообщение будет долго или короткоживущим.
PD
Т.е. платеж может отработать за 200ms, а может и за два дня. Оно, конечно, зависит от параметров платежа, но резать по ним - очень сложно и неудобно.
VN
А не известно заранее, насколько конкретное сообщение будет долго или короткоживущим.
ну ведь предположить изначально исходя из задачи можно или есть области, где это совершенно случаный фактор?
PD
Ну, вот если у тебя платеж с карты на карту - это от 100ms до 30 минут.
А если с карты по номеру счета, то от 100ms до двух недель )
А если с карты по номеру счета, то от 100ms до двух недель )
PD
А если ты послал сообщение на пользователя, то оно или дойдет за 5ms или за десять минут (если он, сволочь, в туннель въехал)
GK
Иными словами, база - как механизм персистентности для FIFO, то есть очереди. При этом ACID будет медленный (ниже пропускная способность), BASE побыстрее (повыше пропускная способность).
Могут быть и другие механизмы персистентности.
Могут быть и другие механизмы персистентности.