Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / Какое хранилище выбрать если будет много insert/update / 25 сообщений из 46, страница 1 из 2
  1  все
09.07.2019, 17:22
    #39835581
redwhite90
redwhite90
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Приходит много данных. В большинстве случаев это insert или update. Транзакции, ссылочная целостность не нужны, поэтому можно использовать NoSql решения. Что-то гугл мне не помогает найти какую-то полезную информацию по этому поводу.
При прочем равном выбор падёт на SQL решение.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:51
    #39835611
забыл ник
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Нужно ли трекать эти insert/update или важно только последнее значение?
Какие типы запросов планируются?
Что даст NoSQL тут по-твоему? В чем затык с реляционной базой? Масштабирование? Репликация? Партиционирование?
Какой объем данных ожидается?

Предварительно можно посомтреть на Cassandra имхо
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:52
    #39835613
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Можно отсюда посмотреть. https://db-engines.com/en/ranking

По сути эта линка - универсальный ответ. Дальше - нужны какие-то детали.
Хотя-бы стоимость лицензии. Будете платить? Или хочется бесплатного?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:52
    #39835614
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90,
Что за хранилище где не нужна целостность и т.д.?))))
Файл возьми. Писать очень быстро.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:53
    #39835615
забыл ник
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
PetroNotC Sharp,
Тоже про файл подумал)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:55
    #39835617
Sergunka
Sergunka
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
PetroNotC Sharpredwhite90,
Что за хранилище где не нужна целостность и т.д.?))))
Файл возьми. Писать очень быстро.

Практически любой временной ряд - просто запись температуры с датчика, там к примеру даже апдейт не нужен.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:57
    #39835618
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Sergunka,
Ну стрим с кинофильмами тоже в файл пишут.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:59
    #39835622
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Это либо TimeSeries (экзотика) либо EventStore. Последнее работает успешно в банках. Написано кажется
на ДотНете и скорость пишуших транзакций у него отличная.

Насчет updates я не уверен. Надо смотреть архитектурно можно ли update рассматривать как еще один
корректирующий insert. Если архитектурно можно - то взлетит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 17:59
    #39835623
Sergunka
Sergunka
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90Приходит много данных. В большинстве случаев это insert или update. Транзакции, ссылочная целостность не нужны, поэтому можно использовать NoSql решения. Что-то гугл мне не помогает найти какую-то полезную информацию по этому поводу.
При прочем равном выбор падёт на SQL решение.

Вроде как Кассандра официальный чемпион по этому делу. Скажите объемы записей в секунду тогда боле-менее будет понятно куда двигатся.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:02
    #39835625
Sergunka
Sergunka
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
PetroNotC SharpSergunka,
Ну стрим с кинофильмами тоже в файл пишут.

Технически в фильме нет временных тегов и особой нужды выбирать по тегу. Во временном ряду это довольно рядовая операция практически любой МЛ алгоритм Anomaly detection на этом построен.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:04
    #39835628
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Ну. Кассандра она имеет лимиты по оперативке. И она больше для UPDATES чеме для INSERTS.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:05
    #39835630
Sergunka
Sergunka
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
maytonНасчет updates я не уверен. Надо смотреть архитектурно можно ли update рассматривать как еще один
корректирующий insert. Если архитектурно можно - то взлетит.

Это в Кассандре реализованно как новая версия для записи. И если мой склероз не изменяет можно вытащить все версии для записи.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:28
    #39835637
redwhite90
redwhite90
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Задача - что-то типа краулинга .SEMRUSH как я понял делает нечто похожее.

Вот тут некто пишет:

https://eax.me/avoid-nosql/ Наконец, Cassandra использует LSM-tree. Этот способ хранения данных подходит далеко не под все нагрузки. Если вы пишите и удаляете много данных (например, решили использовать Cassandra для хранения очередей), это будет работать очень и очень плохо.

Но у нас по идее удалений мало будет
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:30
    #39835638
redwhite90
redwhite90
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Sergunkaredwhite90Приходит много данных. В большинстве случаев это insert или update. Транзакции, ссылочная целостность не нужны, поэтому можно использовать NoSql решения. Что-то гугл мне не помогает найти какую-то полезную информацию по этому поводу.
При прочем равном выбор падёт на SQL решение.

Вроде как Кассандра официальный чемпион по этому делу. Скажите объемы записей в секунду тогда боле-менее будет понятно куда двигатся.

А можно какой-то прув?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:43
    #39835644
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90много данных.цифры то будут?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:49
    #39835651
redwhite90
redwhite90
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
забыл никНужно ли трекать эти insert/update или важно только последнее значение?
Какие типы запросов планируются?
Что даст NoSQL тут по-твоему? В чем затык с реляционной базой? Масштабирование? Репликация? Партиционирование?
Какой объем данных ожидается?

Предварительно можно посомтреть на Cassandra имхо

Ну по масштабированию однозначно NOSQL должна побеждать.


Это было что-то типа преинтервью в проект, поэтому я не знаю всех деталей. Но меня удивила сама постановка вопроса, что упор на то, что много записей и обновлений. Нужно выбрать хранилище заточенное на такие операции. Про запросы на выборку ничего не известно
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 18:51
    #39835654
Leonid Kudryavtsev
Leonid Kudryavtsev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Когда в свое время заморачивался скоростью, меня SQL Lite вполне устроил.

По скорости на простых точечных (одна запись) select/insert'ах раз в 7-8 быстрее PostgreSQL, Основное ускорение (на моей задаче) - отсутсвия протокола TCP/IP между прикладным кодом и БД.

Т.ч. не уверен, что даже Non-SQL memory базы работающие через TCP/IP будут быстрее. TCP/IP (даже loopback) привносит слишком большие издержки.

IMHO & AFAIK
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 19:20
    #39835668
забыл ник
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90Это было что-то типа преинтервью в проект, поэтому я не знаю всех деталей. Но меня удивила сама постановка вопроса, что упор на то, что много записей и обновлений. Нужно выбрать хранилище заточенное на такие операции. Про запросы на выборку ничего не известно
Ну может от вас и требовалось пораасуждать, поздавать наводящие вопросы хз. Ибо формулировка - будет много инсертов и апдейтов лишь вычеркивает все заточенное под OLAP, но не сильно упрощает понимание. Тут надо крутиться от других требований
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 19:23
    #39835670
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90поэтому я не знаю всех деталей.как узнаешь, приходи.
Сейчас твой вопрос равносилен: "нужно перевезти много груза. Что посоветуете"?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 19:51
    #39835683
Leonid Kudryavtsev
Leonid Kudryavtsev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
забыл ник...будет много инсертов и апдейтов лишь вычеркивает...
ну для меня скорее это вычеркивает PostgreSQL с его vacuum или, по крайне мере, заставляет задуматься и проверить пригодность PostgreSQL на тестах.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 20:27
    #39835692
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
Я тоже заметил что PostgreSQL не игрок клуба TPC* тестов где тусят обычно IBM, Oracle, MS.

Наверное стыдится. Хотя JSONB это они здорово придумали.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 20:30
    #39835695
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90Sergunkaпропущено...


Вроде как Кассандра официальный чемпион по этому делу. Скажите объемы записей в секунду тогда боле-менее будет понятно куда двигатся.

А можно какой-то прув?
Никакой она не чемпион. Потому-что конкурса никакого не было. Это ... знаете-ли как чемпионство
среди Стебельков и ФВМясов. Кроме специфичного бенчмарка который написал сам автор никаких других
сравнений не было. Всё нишевое. Специфичное. Вы даже WHERE свободно не можете в кассандре написать.
Предикат не летает для всех полей by default. Просто такова архитектура. Ну а если реально нужно в одной
нише сравнивать. Возьмите сравнение Apache Ignite vs Apache Cassandra. Если таковое сущесствует канешна.

Ну и правила судейства. Что хотим. Скорость транзакций? Это одно. Реакция на падение ноды. И способность
кластера безболезненно ее пережить - это совсем-совсем другое. Вот и попробуйсте просто поставить грамотно
задачу тестирования.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 21:24
    #39835705
redwhite90
redwhite90
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
забыл никredwhite90Это было что-то типа преинтервью в проект, поэтому я не знаю всех деталей. Но меня удивила сама постановка вопроса, что упор на то, что много записей и обновлений. Нужно выбрать хранилище заточенное на такие операции. Про запросы на выборку ничего не известно
Ну может от вас и требовалось пораасуждать, поздавать наводящие вопросы хз. Ибо формулировка - будет много инсертов и апдейтов лишь вычеркивает все заточенное под OLAP, но не сильно упрощает понимание. Тут надо крутиться от других требований

Я думаю, что так и есть. Вопрос собственно в том, чтобы эти ветки выделить и расписать когда что лучше.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 21:33
    #39835707
redwhite90
redwhite90
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
PetroNotC Sharpredwhite90много данных.цифры то будут?

Как обычно в реальном мире клиент надеется, что бизнес будет расти, поэтому хочет заложить наиболее подходящий продукт под требования известные на данном этапе. Пока это должно быть что-то стандартное(не самописное).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.07.2019, 21:56
    #39835710
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Какое хранилище выбрать если будет много insert/update
redwhite90Как обычно в реальном мире клиент надеется, что бизнес будет растиНу дак напишите за него ТЗ и определите сколько миллиардов инсертов нужно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Какое хранилище выбрать если будет много insert/update / 25 сообщений из 46, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 175ms
Закрыть
start [/forum/topic.php?fid=59&tablet=1&tid=2121204]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 56ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 64ms
get tp. blocked users:
 1ms
others: 12ms
total:  175ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]