что делать с конфликтами?

я бы первым делом первичные ключи если они инт сделал гуидами, а потом просто слил с помощьюинсерт инту

как-то так

хотя если у вас много уник констрейнтов, то этот фокус не прокатит и придеьтся потаблично писать скрипты дляслития

я бы первым делом первичные ключи если они инт сделал гуидами, а потом просто слил с помощьюинсерт инту

В чем разница инта и гуида?

в том что автоинкременты наверняка сконфликтуют

https://opencredo.com/cockroachdb-first-impressions/

8к в секунду на три ноды

8к в секунду на три ноды

У меня кассандра на одном серваке. Не тюненая. По умолчанию установленная. Выдает 1.5 милисекуды на запрос

Правда ругается что я с индексами чет там закосячил

И маштабирается она хорошо

ну последовательное выполнение 1.5 мс - это ~650 / сек )

понятно, что там совсем другие цифры будут, но да дело даже не в этом

кассандра тебе только по партишену или по всему кластеру выбирать умеет, никакой паджинации, а это вторая в мире распределенная SQL-совместимая БД

Атомные часы на сервер не нужны?

которая еще и общается по нативному протоколу постгре и имеет поддержку большей части диалекта

желательны

афир полгода назад говорил о расхождении в 20 мс, что ли, после которого начинают проявляться артефакты, но с кластерами внутри одного дц все должно быть в порядке

а это значит, что больше никакой мерзости с переключениями мастеров

кассандра тебе только по партишену или по всему кластеру выбирать умеет, никакой паджинации, а это вторая в мире распределенная SQL-совместимая БД

Ну ей можно прикрутить эластик на бекэнд и огрести кучу плюшек. Но мне не нужен полнотекстовый поиск

Да это все равно вторичные индексы и каждый запрос, уходящий на весь кластер

Да и затюнить ее можно еще

Там не очень линейное масштабирование будет

Ну пишут что она идеально линейно маштбирается

В dse 5.1 sasi завезли, если так сильно вторичные индексы нужны

Ну пишут что она идеально линейно маштбирается

это без ALLOW FILTERING и использования вторичных индексов

там вся соль в том, что она заставляет тебя указать партишен, а по нему известно подмножество серверов, которые могут ответить

при увеличении датасета ты просто добавляешь сервера, а на каждый запрос у тебя отвечает все то же фиксированное количество серверов

отсюда и линейность

Я не разбирался. У меня все равно один старенький сервер

но если работать без партигшена, то запросу не остается ничего, кроме как пройтись по всему кластеру целиком, и тут можно попрощаться с линейностью

Господа, день добрый. Есть простая бизнес-логика: юзер, приход денег на его баланс, уход денег с его баланса. Приход денег с разных источников, уход денег тоже на разные (пару условных платежных систем). Предположим, что текущий баланс юзера уже есть в отдельной колонке (дабы не считать постоянно inc минус out). Статистика прихода\ухода по разным системам будет тоже нужна как минимум администратору. Подскажите, что говорит реляционная теория по поводу того, надо ли объединять входящие\исходящие транзакции в одну таблицу и выносят ли это в реальности в разные таблицы (таблица "income", таблица "outcome").

Какой хороший вопрос...

По поводу теории точно не отвечу, но вот разделение таблиц на практике видел, скажу одно, вынимать данные с двух таблиц тяжелее, чем с одной. Разделение часто не оправдано в подобном примере

Разделение выгодно только тогда, когда по структуре дополнительных данных входящие транзакции кардинально отличаются от исходящих

Разделение выгодно только тогда, когда по структуре дополнительных данных входящие транзакции кардинально отличаются от исходящих

Спасибо, можете пример привести (кардинальных отличий)?

Только сферический

можно и сферический)

Это когда в одной таблице одна запись имеет 50% полей с null ?

И эти нулы скачат от входящих к исходящим

ок, спасибо. А считает ли кто-то баланс не с доп. столбца, а путем вычета income - outcome? С какого момента это начнет тормозить?

Тут от множества факторов зависит

Но мне кажется, лучше все таки заранее рассчитывать баланс и сохранять его в доп столбец

мне просто интересно, когда такой случай денормализуют сразу, а не в тот момент, когда это внезапно начнет влиять на производительность

мне еще надо подсчитывать кол-во income\outcome транзакций, выносить ли это сразу в отдельные колонки или считать обычным count-запросом

Слишком много условий и вашей специфики, чтобы давать однозначные рекомендации

Слишком много условий и вашей специфики, чтобы давать однозначные рекомендации

ок, спасибо в любом случае

ок, спасибо. А считает ли кто-то баланс не с доп. столбца, а путем вычета income - outcome? С какого момента это начнет тормозить?

Кто мешает в таблице юзеров завести столбик баланс для каждого

Иначе упаритесь высчитывать каждый раз когда он делает операцию

Кто мешает в таблице юзеров завести столбик баланс для каждого

так и предполагалось, вопрос в том, когда (в каких случаях) столбик не заводится (мне, допустим, нужно показывать еще и отдельно количество транзакций income, отдельно outcome)

Столбик с балансом лучше завести, иначе бизнес начнет капать на мозг

Транзакции тоже можно

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

так и предполагалось, вопрос в том, когда (в каких случаях) столбик не заводится (мне, допустим, нужно показывать еще и отдельно количество транзакций income, отдельно outcome)

Ну я бы сделал отдельные таблицы Юзеры (вся инфа и баланс текущий) Транзакции ( ид юзера. Время. Сумма. Отметка приход или расход. Откуда или куда. Табличка откуда/куда

И не теребонькал бы без толку

Ну я бы сделал отдельные таблицы Юзеры (вся инфа и баланс текущий) Транзакции ( ид юзера. Время. Сумма. Отметка приход или расход. Откуда или куда. Табличка откуда/куда

спасибо, я остановился пока что на таком же варианте, единственное пока - возник снова нестандартный вопрос, если у меня не добавится\изменится тип прихода\ухода (ближайшие пол года-год, например), стоит ли под это дело заводить отдельную таблицу или лучше положить в enum

А когда изменится тогда бегать в панике?

И рвать волоски в неудобных местах?

почему же бегать в панике?

Переделывать

А оно там логикой обрастет уже

ERROR: S client not available

Будет весело

я понял, да, ответственность переносится больше на логику.

Ок, а такой момент - если ко мне внезапно приходит бизнес с идеей "а давайте еще и переводы м\у юзерами сделаем", соответственно попимо нового типа income\outcome, мне еще надо хранить id юзера отправителя\получателя. Что делать в таком случае, оставлять в этой же таблице?

Почему и нет

Ок, а такой момент - если ко мне внезапно приходит бизнес с идеей "а давайте еще и переводы м\у юзерами сделаем", соответственно попимо нового типа income\outcome, мне еще надо хранить id юзера отправителя\получателя. Что делать в таком случае, оставлять в этой же таблице?

Если можно выделить в отдельную логическую сущность, выделяй

Если это свойства текущей сущности, добавляй поля

Если это свойства текущей сущности, добавляй поля

По логике, свойство текущей, да, но тогда у большинства записей в столбце "юзед id" будет нулл

Ну так руки ноги тоже не у всех людей есть

Тут надо смотреть ещё на отнощение

Ок, а такой момент - если ко мне внезапно приходит бизнес с идеей "а давайте еще и переводы м\у юзерами сделаем", соответственно попимо нового типа income\outcome, мне еще надо хранить id юзера отправителя\получателя. Что делать в таком случае, оставлять в этой же таблице?

eav

eav

Это сложновато конечно (проект для себя делается), но я идеи понял

Ок, а такой момент - если ко мне внезапно приходит бизнес с идеей "а давайте еще и переводы м\у юзерами сделаем", соответственно попимо нового типа income\outcome, мне еще надо хранить id юзера отправителя\получателя. Что делать в таком случае, оставлять в этой же таблице?

Дык в таблице транзакций же.

Это сложновато конечно (проект для себя делается), но я идеи понял

Очередная домашняя бухгалтерия по взрослому без трусов?

Очередная домашняя бухгалтерия по взрослому без трусов?

Нет, но связано с деньгами (криптой) и каким-то количеством юзеров, поэтому стараюсь подходить серьезно

за eav руки отрывать уже проектировщикам готов.

если есть возможность избежать, лучше избежать.

Да в монгу фигачить и делов ?

в самом деле, что это я :)

за eav руки отрывать уже проектировщикам готов.

Отрывать руки это как бы жестоко слишком. Может для начала головы отворачивать :)

Лол как вы еще с неструктурированными данными будете работать?

А мы не ищем легких путей. Мы создаем себе трудности, что бы потом мужественно их преодолевать и гордится этим. :)

Лол как вы еще с неструктурированными данными будете работать?

структурировать ?

лол

ой эксперты понабежали

чувак спрашивает - если мне внезапно прилетит ебаная хуйня, что я с этим могу сделать в ограниченное время?

не зная ее наперед