Хранение большого объема данных

не сдохнет. если выборку по айди делать

Clickhouse может подойти. 1Тб там это нормальное количество. Если кеш нужно чистить по дням, например удалить все старше 30 дней то тут подойдут подневные партиции (по умолчанию там месяц кажется).

Немного не то. За совет спасибо.

Clickhouse не про это, она коллоночная база данных, она скорее про аггрегацию значений и постоянную запись, и про всякие паттерны 3д кубов и прочего. Это OLAP, автору на сколько я понял нужно OLTP.

Зачем вам JSON тип? Вы по нему искать собираетесь? Если да, то лучше PostgreSQL, или на крайняк Mongo. Если искать по JSON нет нужды - берите любую СУБД, поиску присваиваете идентификатор, JSON не храните в типе JSON, т.к. там валидация происходит. Просто берите BLOB и храните массив байт.

На счет справится/не справится, справится и с бОльшим количеством. Делаете партиции и все будет работать вполне себе.

А вообще, структура ваших данных и необходимые выборки до конца не ясны.

1) Без проблем, хотя nosql база данных при таком объеме будет лучше.

2) Плохая идея. json / генерируемые столбцы хранятся виртуально, а не реально физически. И несмотря на возможность индексации - поиск по ним будет достаточно тормозным. Делайте таблицу с реальными полями по которым будет поиск (только с ними), полные json данные храните в отдельной таблице вообще (например в таблице из пункта 1). Если сможете нормализовать данные - будет вообще шикарно, но это как бы и так очевидно.

а) mysql такой объем вполне готов переваривать, но обратите внимание на myisam вариант. innodb неплох, но в сравнении с myisam может быть тормознее на относительно простых запросах.

б) если это хоть как-то возможно, используйте не утф8, а однобайтовую кодировку. Эта статейка до сих пор актуальна и такой вариант может сэкономить Вам реально много ресурсов.

1) nosql и прочие монги шмонги не будут лучше.

2) просто json можно хранить в текстовом поле и нормально по нему искать при этом, лишнего кода и объема это не добавляет.

P.S. я помню так в sqlite хранил кеш запросов к апи партнерки где слон. 50 гб файл нормально жил :D хотя это было не самое умное решение.

---------- Добавлено 28.04.2019 в 10:28 ----------

А по поводу объема, если поиск по этим текстам не нужен и все запросы по id , то текст (json) должен отлично сжиматься через gzdeflate, если текста в каждой ячейке много.

Когда пишете NoSQL, пишите какая именно. Бывают варианты для полностью противоположных задач.

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

Я так понял, там особо нечего нормализовать. Есть какой-то идентификатор, и куча байт которые нужно вернуть.

Да, действительно, обратите внимание на движок, который при малейшем сбои может покорраптить все таблицы. Приведите примеры, на каких запросах может быть тормознее (кроме COUNT(*))

Кстати, да. Но если нужно сжатие, я бы взял MyRocks, мы так одну базу до 400Гб ужали (с 1Тб)

Сейчас вот как раз есть одна толстая таблица на почти 3 млрд строк:

SELECT table_rows FROM information_schema.tables WHERE table_name = 'my_table_name';

+------------+

| table_rows |

+------------+

| 2795222610 |

А вот время выборки по PK:

379 rows in set (0.017 sec)

Таблица без партиций, кстати. Можно сделать PARTITION BY HASH(col) PARTITIONS 20; и будет все ещё быстрее работать

Наверное все таки зависит от того что надо, а в данном случае это не до конца ясно. С учетом того, что

я бы монгу-шмонгу и пр. носкуэл не исключал. Например, каждая категория - отдельная коллекция (таблица в терминах скуэл бд), их, категорий,например, в Я-маркете, если не изменяет память что то между 2000-3000. Порядок цифр примерно ясен, явно меньше 24000 .

А дальше дело техники

db.fotoapparaty.find( { optzoom: { $gte: 40, $lte: 80 } } );

db.planshety.remove( { addtime : { $lt : new Date(2018, 12, 31) } })

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

И диапазоны? Ну типа "Оптический Zoom от 40 до 80"

Для задач ТС - по фиг.

Нет.

Возможно, но в пункте 2 есть "набор полей", а не просто "ид и дсон".

Холивары на эту тему отгремели лет 5 назад уже, мы не будем это начинать тут и сейчас, но просто отвечая на вопрос - при небольшом сбое ничего не будет, при среднем - майисаму понадобится репаир тейбл и все на этом, при крупном - иннобд умрет а майисам потеряет часть данных. И не забывайте какой размер логов бинарных транзакций будет на базе размером в 500гб.

https://www.percona.com/blog/2009/01/12/should-you-move-from-myisam-to-innodb/ до сих пор актуальная статья.

Бггг, ну и бред. Т.е., берем любую TSDB и пишем туда. Отличный совет. Уже на этом можно прекращать дискуссию, но ладно.

Да.

Это прямо из документации вырезка.

Какой, если я их отключу, а буду использовать redo log из InnoDB?

• Table level locking
• Не ACID compliant
• Не умеет самовосстанавливаться, если упадет ночью - будет простой
• Глобальный лок при бекапе (логическом и физическом), когда будете делать бекап - позовите меня, посмотрю как все ждут когда бекап базы на 500 гб закончится.

Да, как и все другие статьи вышедшие 10 лет назад.

Я бы ещё понял если бы вы посоветовали использовать MyISAM под табличку которая никогда не изменяется, используется под read-only, и в ней 500 не важных строк.

Ладно, не хочу время тратить на этот бессмысленный спор. Используйте и дальше MyISAM, пока его не выкинут из MySQL.