или же здесь уже какие то другие механизмы нужно реализовывать?

там выше написали, как это делается на практике

У меня был проект, когда я по 300к записей в день лил в MS SQL из яндекс маркета. Когда записей в таблице стало под 50 млн, мне пришлось лепить кучу индексов. Проблема в том, что бизнес меня ограничивал в железе и ставил цель быстрого получения данных. Я это реализовал, но я забил на скорость загрузки (для проекта было не критично) и в последствии у админов были проблемы с бэкапами, т.к. места это занимало прилично...

На мой взгляд, Ms SQL не очень для таких масштабов... И да, версия была 2005, возможно в новых версиях они сделали лучше...

а сейчас сколько данных там накопилось?

Я уже полтора года, как не работаю с этим проектом

ясно

спасибо

В общем, на этих объемах уже лучше забывать как про нормализацию, так и про реляционки, а все запросы сводить к простому получению данных по ключу или листингу значений по части ключа. Потому что ничего дешевле для движка придумать не получится, ему остается только вычислить ответственные ноды по значению ключа, спросить N из них о том, что там такое валяется, а они благодаря индексу уже знают, в каком месте искать.

Поэтому выброси из головы MSSQL, нормализацию и найди человека, для которого такие вещи не будут новостью

Ну и про индексы (кроме автоматического первичного ключа) лучше тоже забыть, просто под каждую выборку готовить свою таблицу. Если движок позволяет сделать это автоматом через какой-нибудь mv - ок, нет - делать руками при каждом апдейте

В общем, на этих объемах уже лучше забывать как про нормализацию, так и про реляционки, а все запросы сводить к простому получению данных по ключу или листингу значений по части ключа. Потому что ничего дешевле для движка придумать не получится, ему остается только вычислить ответственные ноды по значению ключа, спросить N из них о том, что там такое валяется, а они благодаря индексу уже знают, в каком месте искать.

Как думаете как вариант использовать MongoDB ?

И идеи про поиск в БД сразу тоже отложить в глупое лето

Вариант, нанять человека

думаю, что ты просто прочел название в интернете и сейчас предлагаешь его на м

Вариант, нанять человека

спасибо уже предлагали!

стоит рассмотреть его еще раз

думаю, что ты просто прочел название в интернете и сейчас предлагаешь его на м

Не правильно думаете

спасибо за совет

ну, опровергни меня тогда

чем? я же говорб я не базист

я его начал изучать

в связке с ТNodejs

NodeJs

я примено такое и имел в виду. тебе надо изучать гарантии хранилища и принципы внутренней работы, чтобы их сравнивать, а не смотреть хипстерские скринкасты возможностей и интерфейс. монгой не пользовался, но и ничего хорошего не слышал, некоторые вещи, которые смотрел, вызывали вопросы.

у тебя вообще первый вопрос должен быть, нужно ли тебе неструктурированное хранение и сможешь ли ты его вывезти на хранилище со строгой структурой, если понадобится

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

и из-за этого я с большим неудомением воспринимаю прыжок mssql -> mongo

у тебя вообще первый вопрос должен быть, нужно ли тебе неструктурированное хранение и сможешь ли ты его вывезти на хранилище со строгой структурой, если понадобится

тут важна скорость, если для проекта изначально будет строится неструктурированное хранение, то и в дальнейшем так и останется

и, под конец, я тоже не базист

not that shit again

sla озвучьте

не будет нужды переводить

что такое скорость? миллисекунда? десять? сто?

мс

что мс?

и, под конец, я тоже не базист

на это и смахивало

лол

обработка запроса в миллисекундах

сколько?

я могу посоветовать аэроспайк как одно из самых быстрых решений, с которым работал, но они, я так понимаю, забивают на консистентность

могу посоветовать кассандру, но это тоже все вилами по воде

поэтому, пожалуйста, sla в студию

Как думаете как вариант использовать MongoDB ?

У монго тоже свои затыки, знаю проект, где в неделю по 50 млн записей, если отбросить моменты индексации, то там отдельная БД на неделю

спасибо уже предлагали!

И ещё раз 100 предложат, крепитесь.

ну с тобой-то мы еще mysql ему можем предложить

вот в кждой группе есть такие занозы)

А вообще да, если нужно поднять проект - нанимайте человека.

А вообще да, если нужно поднять проект - нанимайте человека.

?

В противном случае ставьте эксперименты сами

да придется походу

А как вы хотели по другому? ?

вот в кждой группе есть такие занозы)

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

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

Нету желания и времения с тобой спорить

Чтобы что-то рекомендовать, нам надо понимать всю архитектуру и структуру, какой входной поток, какой выходной, какие скорости нужны, какие скорости имеем, какое железо, какой бюджет и прочие прелести жизни

угу. и этой информации вообще по нулям. "нужно, чтобы было быстро".

И шардинг!

ну с тобой-то мы еще mysql ему можем предложить

Зачем? Человек написал вводные, Вы ведь вновь их не читали.

ясен хер, что нужно, чтобы было быстро, это 2016, все хотят чтобы было быстро

Чтобы что-то рекомендовать, нам надо понимать всю архитектуру и структуру, какой входной поток, какой выходной, какие скорости нужны, какие скорости имеем, какое железо, какой бюджет и прочие прелести жизни

да мне нужно было приблизительное направление, типа для работы с большими данными луче использовать такую архитектуру лиюо такую БД

мало или много получил

Зачем? Человек написал вводные, Вы ведь вновь их не читали.

да, общее количество записей, но ни распределения по конкретным типам, ни запросы, которые к ним пойдут, ни sla

Есть идея фикс, всех таких отправлять на монгу :)

В противном случае ставьте эксперименты сами

Дык он и ставит, приходит, спрашивает по сути, как эксперемент получше сконфигурировать.

После того как намаются с монгой может мысли какие то появятся

да, общее количество записей, но ни распределения по конкретным типам, ни запросы, которые к ним пойдут, ни sla

Для этого стоит научится вести диалоги, задавать вопросы, а не сходу выдавать однотипные неуместные советы.

я там спрашивал выше, если что

ERROR: S client not available

я там спрашивал выше, если что

А, извини, сегодня Чистяков отличился, у вас аватарки в миниатюри в схожих тонах, я вас перепутал

Кто говорил что про поиск в миллиарде записей можно забыть ))

не могу найти это сообщение

Это вроде смешно, нет?

Я конечно нуб, но в сикстилионе записей, упорядоченных по алфавиту, поиск займет.. ну от силы 100-120 итераций

да мне нужно было приблизительное направление, типа для работы с большими данными луче использовать такую архитектуру лиюо такую БД

Для работы с большими данными можно взять колоночную БД и Anchor model, но подойдет ли это вам или наоборот, навредит - это вопрос...

или не сикстилион, ну короче 1 * 10^21

это к примеру прост

Может я не прав, поправьте тогда меня

Под итерациями я подразумеваю деление на 2

И идеи про поиск в БД сразу тоже отложить в глупое лето

вот нашел

Я конечно нуб, но в сикстилионе записей, упорядоченных по алфавиту, поиск займет.. ну от силы 100-120 итераций

А сколько это по времени?

Ну а сколько времени надо, чтобы 120 раз разделить на 2

только вот столько данных не бывает )

наверное

1 000 000 000 000 000 000 000

ну во всяком случае это число делится на 2 всего 70 раз до получения единицы

Теоретики такие теоретики..

Да я не теоретик, честно говоря я вообще никто ) Просто пытаюсь думать логически. Если база проиндексирована, то в чем может быть проблема с поиском

гугл же ищет как-то

Теоретики такие теоретики..

Лол ну

Да я не теоретик, честно говоря я вообще никто ) Просто пытаюсь думать логически. Если база проиндексирована, то в чем может быть проблема с поиском

OOM

Поиск поиску рознь

Даже индексам надо где-то хранится

Поиск поиску рознь

Так понятно, что перебирать все записи накладно. Не думаю, что так кто-то делает )

Даже индексам надо где-то хранится

Я только про поиск говорил, а не про хранение...

Да, но ведь искать надо где-то?

То есть искать надо в структуре индекса

её надо где-то держать, в идеале в памяти.... НО

Я конечно нуб, но в сикстилионе записей, упорядоченных по алфавиту, поиск займет.. ну от силы 100-120 итераций

дорогой мой, упорядочь записи по десяти атрибутам, пожалуйста

У меня сейчас база, 80М записей, данных 22ГБ, а индекса на 7,5ГБ