Добрый день. Тупой вопрос, согласен, но надо уточнить не допускаю я ошибку по безопасности. Представим сайт блог или магазин. Можно ли хранить товары, посты и всю инфу где нет приватных данных в JSON, а не в БД? Какие минусы и плюсы данного метода? Мне это нужно чтобы снизить нагрузку на БД. И если можно, как лучше делать, хранить чисто в JSON, либо добавлять новые посты или товары в JSON и БД, а инфу брать чисто с JSON?
Можно, но это будет очень глупо, особенно по причине "снизить нагрузку на БД". Не переживайте, пупок у СУБД не развяжется от ваших пяти посетителей в месяц, просматривающих семнадцать товаров. Он не развяжется даже при объёмах на пять порядков больших.
Плюсов у такого подхода примерно ноль в обычных проектах, а минусы - всё остальное.
То, что вы хотите заколхозить, называется кэширование и для него есть куча готовых нормальных решений.
Извините, я не верю, что у вас на проекте 50 000 одновременных пользователей и при этом нет ни одного компетентого человека, который понимает, что хранить данные в JSON-файлах не нужно. Больше похоже на влажные фантазии.
У вас уже прямо сейчас есть конкретные проблемы с нагрузкой на БД, которые нельзя решить оптимизацией алгоритмов и запросов? Полагаю, что нет, и вы занимаетесь преждевременной оптимизацией придуманных будущих проблем. Попытка предсказать проблемы и их заранее устранить - это не всегда плохо, но в данном случае и проблема надуманная, и решение этой надуманной проблемы предложено плохое.
P.S. У меня на одном проекте есть таблица с ~6 000 000 000 строк, занимающая почти полтерабайта. Вот там пришлось ещё слегка обмазать Редисом, чтобы не заставлять пользователя ждать окончания вставки новых значений.
У меня на одном проекте есть таблица с ~6 000 000 000 строк, занимающая почти полтерабайта.
Чисто для интереса, можете, пожалуйста, указать какая СУБД. И, если можно, число индексов.
Сколько по времени занимает вставка 1 строки?
Обычно ближе к 1млрд. идет достаточно сильная деградация. Хотя 80 байт на строчку не так много, неаверное благодаря этому нет особых проблем.
Vitsliputsli, mysql 8. Индекс там только один, от двух внешних ключей пришлось отказаться для ускорения вставки, когда начались проблемы со скоростью.
Из-за этих же проблем пришлось сначала класть пакет с данными (от сотни тысяч до миллиона строк за раз) в Redis, а потом уже оттуда фоновый процесс записывает непосредственно в таблицу. Поэтому даже не знаю теперь сколько занимает вставка - пыхтит там себе в фоне и никого не беспокоит.
Алексей Уколов, спасибо большое, очень интересно.
Да, внешние ключи первый кандидат на выброс при высокой нагрузке, я их вообще не использую, уж очень они замедляют работу.
Похоже из-за 1 индекса и небольшой длины строки вам удается вытягивать такое огромное кол-во. У меня примерно те же полтерабайта, но треть миллиарда строк (и где-то полтора десятка индексов), при увеличении кол-ва уже не так все быстро, как хотелось бы, хотя данные партиционированы горизонтально (2 таблицы 1 к 1). Но у меня и требования другие, вставки - это несколько миллисекунд, больше 10мс уже слишком долго. Да и данные не могу отложенно складывать. А с шардированием все очень сложно, не получается выбрать оптимальный параметр по которому шардироваться, т.к. запросы на выборки очень разные.