Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / C++ |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все |
mayton Member Откуда: loopback Сообщений: 51016 |
Вопрос задан как-то странно. "Мало ли..." Скажу так. Я встречал много плохих приложений которые благодаря законам и гарантиям RDBMS худо-бедно работали. И я встречал "очень модные" попытки писать данные в Windows/NTFS и AWS/S3 которые впоследствии становились мусорной свалкой где нельзя было ничего гарантировать и бизнес-логика должна была просто учитывать возможные ошибки неконсистентности как данность. |
||||
21 мар 21, 21:30 [22297965] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
Что это за волшебная библиотека если не секрет? Я сейчас выпил два по 0.5 светлого и очень сентиментален и уже готов взять в объятия это чудо и полюбить его крепче чем Oracle в БД и Erlang в отказоустойчивых системах. |
||||
21 мар 21, 21:33 [22297966] Ответить | Цитировать Сообщить модератору |
Siemargl Member Откуда: 010100 Сообщений: 6422 |
Ах да, темка то %$#!@, но зачем? |
||||||||
21 мар 21, 23:27 [22297998] Ответить | Цитировать Сообщить модератору |
White Owl Member Откуда: Сообщений: 12682 |
Стоимость поддержки изменений в любой БД (реляционной и не) измеряется в IO. Хочешь обновить одну запись? Читаем с диска в память индекс, в нем находим где в таблице находится нужная запись, читаем тот самый сектор с диска, обновляем данные в памяти, записываем обновленный сектор обратно на диск. Если условия поиска записи не попадает ни под один индекс - поочередно читаем с диска всю таблицу, проверяем каждую запись на совпадение с условием поиска. Если хочешь создать новый индекс - поочередно читаем с диска всю таблицу, строим индекс, записываем его на диск. Самое дорогое - IO с диском. Поэтому и стараются давать кэши побольше, SSD диски побыстрее, индексы поточнее. Нету никаких "единиц" есть только чтение-запись с диска. |
||||
22 мар 21, 01:03 [22298009] Ответить | Цитировать Сообщить модератору |
White Owl Member Откуда: Сообщений: 12682 |
|
||||||||
22 мар 21, 01:04 [22298010] Ответить | Цитировать Сообщить модератору |
White Owl Member Откуда: Сообщений: 12682 |
update table1 set counter = counter + 1 where id=1234;будет получше слегка :)
create table nodes( node_id text primary key, last_ip text, last_port int ); create table node_counters( node_id text primary key, pings_requests counter, get_peeers_requests counter, find_nodes_requests counter );В одной таблице описание объекта, в другой счетчики. Причем с точки зрения производительности будет лучше даже не одну таблицу, а три сделать: create table node_counter_pings( node_id text primary key, pings_requests counter ); create table node_counter_peers( node_id text primary key, get_peeers_requests counter ); create table node_counter_requests( node_id text primary key, find_nodes_requests counter );Чем меньше таблица в ширину, тем больше записей влезает на одну страницу. И при условии что надо будет обновлять несколько записей подряд - вместо одного IO на каждую запись может получиться один IO на несколько записей. Тут может помочь кластерная индексация, хотя это и не совсем совпадает с твоей текущей задачей. А работать с этим ты будешь также как и раньше, просто в одну таблицу пихаешь описание ноды, а потом дергаешь счетчики во вторичной таблице. insert into table_with_info (id, description) values (1234, 'some entity'); update table_with_counter counter = counter+1 where id = 1234; |
||||||||||||
22 мар 21, 01:20 [22298011] Ответить | Цитировать Сообщить модератору |
White Owl Member Откуда: Сообщений: 12682 |
|
||||||||
22 мар 21, 01:32 [22298012] Ответить | Цитировать Сообщить модератору |
White Owl Member Откуда: Сообщений: 12682 |
И нет, это не шутка, она действительно так называется :) |
||||||||
22 мар 21, 01:34 [22298013] Ответить | Цитировать Сообщить модератору |
crutchmaster Member Откуда: оттуда. Сообщений: 2242 |
mayton, ФС как база данных. ![]() Сценарии, когда такое прокатит и всё такое. Сообщение было отредактировано: 22 мар 21, 06:21 |
22 мар 21, 06:28 [22298023] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
dBase видел. Мы грузили с него телефонный трафик в Oracle. Бухгалтерию не видел. Мы как раз смигрировали с одной старой dbf-системы на Парус предприятие. |
||||||||
22 мар 21, 11:17 [22298109] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
Не могу согласится с таким разбиением. В инженерных задачах - эстетика тоже важна. А я - большой эстет. Я не ставлю себе задачей - суждать физический размер data-row. Эта цель - специфична для bigdata - технологий. И оптимизация попаданий в кеш-линию мне тоже не нужна пока. Мне важнее то насколько удобно я буду видеть статистику реквестов по нодам. Тем более что они связны. Если нода сделала ping. То следующим реквестом оа запросит список известных пиров или другиг нодов. Корреляция выходит. И зачем мне тогда таблицы нарезанные узкими полосками? Тут самое толстое поле - это первичный ключ. Разумнее склеивать. |
||||
22 мар 21, 11:22 [22298113] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
mayton, А разве сам движок БД не мог бы размещать столбцы по отдельности, если в определённых ситуациях это производительнее? Потому что размещать атрибуты в отдельных таблицах — это беспредел. |
22 мар 21, 11:31 [22298122] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
Apache ORC и Parquet так и делают. Но это не движки DBMS. А движки неких замороженных снимков данных для аналитики. Обычно они - исторические. По сути это форматы бинарного хранения больших данных. Даижком это назвать вряд-ли можно. |
||||
22 мар 21, 11:56 [22298145] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34688 |
Очень просто же, вешаешь мьютекс именованый глобальный, если создал -- ты первый. Если мьютекс уже был создан -- приложение уже было запущено, и ты завершаешься. Либо также можно глобальный атом делать, либо другой любой именованый объект межпроцессного взаимодействия. (в линуксах для этого используют часто реальные файлы в файловой системе) |
||||
22 мар 21, 12:18 [22298155] Ответить | Цитировать Сообщить модератору |
PetroNotC Sharp Member Откуда: Сообщений: 7650 |
mayton, Нужны какие то тесты что ли.... Показывающие что "вот схема классик и бд не справляется" = наличие проблемы. А вот схема заточенная на решение проблемы. Ну а по теории, строят Логическую и Физическую схему. В логической бизнес. В физической ключи, отношения, типы и последовательности. |
22 мар 21, 12:23 [22298162] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
Нет-нет. Нету пока никаких тестов. И нету проблемы. Есть просто вопрос эстетики. Мне не нравится когда таблица порезана на 3 вертикальных полоски просто так. В угоду идеям перформанса. Я не знаю какова должна быть просадка перформанса (явно больше 1000%) чтоб я начал думать о порезании таблич на куски. Да и не ставлю я пока таких вопросов. Давайте поскипаем эту тему. Я подниму ее чуть позже в Программировании в разрезе самого сетевого протокола. |
||||
22 мар 21, 12:57 [22298187] Ответить | Цитировать Сообщить модератору |
PetroNotC Sharp Member Откуда: Сообщений: 7650 |
mayton, Полоски это партицирование? >поскипаем = ОК |
22 мар 21, 13:23 [22298195] Ответить | Цитировать Сообщить модератору |
petrav Member Откуда: Сообщений: 2861 |
Вообще мне всегда казалось, что NoSQL был рождён из-за недостатков SQL. Проблема реляционных баз данных в плохой масштабируемости. Когда возникает big data и тебе нужны десятки тысяч серверов БД по всей планете, то SQL не справляется. Да, NoSQL не гарантирует связанности данных, но мы ей жертвуем, что бы юзер хотя бы что-то мог найти в нашей распределённой БД. Но в данном диалоге прослеживаются такие нотки, что мол вообще можно/нужно использовать NoSQL просто повсеместно. Просто потому что это модно и молодёжно. |
22 мар 21, 13:31 [22298201] Ответить | Цитировать Сообщить модератору |
Dimitry Sibiryakov Member Откуда: Сообщений: 52921 |
Да, но не тех, о которых ты говоришь. Когда очередной энтузазист делает свою собственную СУБД с покером - он не осиливает полный парсер и оптимизатор SQL поэтому выкидывает его и преподносит прямой доступ к внутренним структурам и функциям как достоинство. STFW FwMas. Posted via ActualForum NNTP Server 1.5 |
||
22 мар 21, 13:45 [22298208] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
По поводу поля counter. Я думаю что все просто. Запросы с инкрементом - не идемпотентные. А поскольку Apache Cassandra гарантирует работу таблиц одной базы в пределах земного шара - то ей нужны внятные механизмы репликации которые не сломают реплику. Скорее всего такое разделение введено с целью разделить два протокола. Один - простой для UPDATE .. SET field = value. А другой для UPDATE .. SET field = f(field) который требует повышенного внимания в дубликатам сетевых собыйтий. |
22 мар 21, 16:19 [22298309] Ответить | Цитировать Сообщить модератору |
White Owl Member Откуда: Сообщений: 12682 |
|
||||
22 мар 21, 16:21 [22298311] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
Хм... это мысль. Впрочем я пока думаю выкинуть Кассандру и вернуться к Postgresql. Это был творческий эксперимент. Он наполовину удался. Я доволен. |
22 мар 21, 16:24 [22298313] Ответить | Цитировать Сообщить модератору |
PetroNotC Sharp Member Откуда: Сообщений: 7650 |
mayton, - чтобы гарантировать в пределах земного шара достаточно не совпадения PK. Одно из решений GUID - при GUID реплика не ломается |
22 мар 21, 16:25 [22298315] Ответить | Цитировать Сообщить модератору |
PetroNotC Sharp Member Откуда: Сообщений: 7650 |
|
||||
22 мар 21, 16:27 [22298317] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 51016 |
Почему? |
||||
22 мар 21, 16:32 [22298321] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все |
Все форумы / C++ | ![]() |