Как оптимально работать с данными в JSON?

Question

[d'Ivan]

На SQL Server 2012 запущен сервис, на вход к которому поступает огромный JSON, представляющий из себя массив из 500-800K товаров с десятком атрибутов.
Этот JSON сжат в Zip и потом обёрнут в Base64 (да, да, это такая экономия!). Каждый такой ком данных поступает регулярно от разных удалённых клиентов, распаковывается и построчно складывается в таблицу СУБД с заранее определённой структурой. И при этом все эти записи некоторого клиента должны быть полностью выкинуты и заменены на новые при поступлении нового JSON. Получается нехилый такой I/O в связи с записью. Нередко требуется искать по тем записям товар при помощи LIKE, что очень неэффективно.
Альтернативой предлагается записывать упакованные данные как есть в виде BLOB и для каждого поиска товара распаковывать в памяти всю ту структуру JSON и искать уже по ней.
Что по-вашему более эффективно по времени, по хранению и по I/O?
Или же другие варианты?

Answer 1

[res2001]

Вставлять большой массив данных в SQL лучше с помощью bulk insert, но, на сколько я помню, эта операция не понимает json (нужно уточнить). Можно из json конвертнуть в csv (или во что-либо другое, с чем bulk insert работает), а потом уже вставлять в sql. JSON преобразовать в csv можно достаточно простым скриптом на javascript.
Чтоб быстро работал поиск, нужно сделать соответствующие индексы.
Предложенный альтернативный вариант можно считать рабочим, только если нет сильно удаленных клиентов с не слишком быстрыми каналами связи (и вообще их не очень много), кроме того, чтоб не таскать на каждый запрос этот огромный BLOB можно вытянуть его один раз при старте клиента, а потом уже искать только локально.
Но, как по мне, вариант с загрузкой в SQL вполне рабочий.

Answer 2

[Алексей Черемисин]

Взять elasticsearch и в нем делать поиск, собственно в нем и хранить сами данные можно.

Comments

[d'Ivan]

Обоснуйте решение, пожалуйста.

[Алексей Черемисин]

Во первых, мы тоже делаем магазин, во вторых - я так поступал еще лет 10-15 назад, когда небыло ни solr, ни эластика, а была голая люсина. В третьих - поиск очень эффективен и на порядки быстрее базы данных. В четвертых - индекс гораздо легче просто убить и создать новый. В пятых, там где нужна связанность, ее можно сделать и в базе данных, или делать искуственные транзакции. Ну и в шестых - это красиво.