Mysql Структура БД EAV, кто работал с ней в посещаемых сайтах?

Добрый день!
Подскажите кто работал с EAV в посещаемых сайтах?
У меня сайт, на котором планируется более 3000 магазинов, порядка 18000000 товаров.
Посещаемость сайта, планируется не меньше 3-4 тысяч в день.
Сейчас структура такая:
- одна таблица с товарами и общими свойствами, такими как название, цена, производитель и т.д.
- на каждый товар своя таблица со свойствами для данного товара
- таблица цвета товара, в которой может быть несколько строк для одного товара, в зависимости от количества цветов у товара
- таблица материалов, то же самое, что и для цвета.
Число таблиц со свойствами растет, так как товары все разные.
Если надо, что то поменять, уходит куча времени.
Решил почитать про EAV очень удобная структура для интернет магазина, но многие жалуются на скорость при большом количестве записей и посетителей.
Скажите, у кого есть опыт в проектах типа такого как у меня и кто использует EAV , что ждет меня при тех параметрах которые я описал в случае работы с EAV, подскажите альтернативу из уже сделанных Вами проектов
Спасибо большое!

да много у кого есть, у нас в магазине было пол-миллиона позиций с трафиком на уровне 700 к уников,

тебя ждет встреча с реальностью, ибо твои 3-4 тысячи посетителей в день никому не интересы, количество магазинов/позиций будет меньше раз в 100,
а тысяч с 20 посетителей в сутки ждет поиск инвестиций, найм технического руководителя, команды, DBA, админа, финансового директора, и, возможно, операционного директора вместо себя, кто не просрет все полимеры, как большинство

выбрось mysql пока не поздно

postrgresql / jsonb + gin/gist прекрасно подойдет для твоего кейса

fixxxer написал(а):

postrgresql / jsonb + gin/gist прекрасно подойдет для твоего кейса

Нажмите для раскрытия...

Целостность данных для слабаков?

fixxxer написал(а):

postrgresql / jsonb + gin/gist прекрасно подойдет для твоего кейса

Нажмите для раскрытия...

посчитай количество часов, которые надо потратить на изучение с почти нуля.
3-4 тысячи уников в сутки тянутся vps-кой за $20 в месяц без оптимизаций на почти любом стеке.
я тоже люблю постгрес, просто ему это будет тяжело

grigori написал(а):

посчитай количество часов, которые надо потратить на изучение

Нажмите для раскрытия...

ммм... 10 минут?

дада, новичок за 10 минут прочтет доки, поставит постгрес, настроит shm, подтюнит автовакуум и хотя бы поймет разницу между gin и gist. ога
конечно, для роста постгрес лучше, чем mysql, но там не то что 18 миллионов, там и 100 тысяч позиций не будетпо факту

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

Boris написал(а):

Скажите, у кого есть опыт в проектах типа такого как у меня и кто использует EAV , что ждет меня при тех параметрах

Нажмите для раскрытия...

С выборками проблем не будет. А вот поиск по многим критериям погоду ухудшит. Так что зависит от того, сколько групп условий будет в магазине для поиска. Чем больле - тем раньше придется что-то думать отдельно для поиска.
А 3-4 тысячи в день... вообще ниочем. Даже если они придутся на рабочее время, даже если половина прийдет в "час-пик" за пару часов... дай бог несколько запросов в секунду получите.

MiksIr написал(а):

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

Нажмите для раскрытия...

да, при условии, что руководитель/заказчик на это согласен, но если проект свой и в мамином холодильнике есть котлеты - конечно

MiksIr написал(а):

Целостность данных для слабаков?

Нажмите для раскрытия...

Обычно в параметрах тупо свалка и никаких связей (я ж не предлагаю туда category_id пихать), но если вдруг надо - ничего не мешет хранить в EAV и триггером денормализовывать в jsonb.

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

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

P.S. простите? сбил с толку? не 18000000 товаров, а порядка 3000000 товаров у каждого из которых не менее 5-6 параметров, что составит порядка 18000000 записей в таблице, если использовать EAV.
Может быть Вы правы и я не приближусь к этим цифрам, но я рассчитываю по максимуму ,так как лучше готовиться к большему, а с меньшим всегда справишься.
Спасибо!

Реляционные базы данных - это как раз Postgresql и Oracle. MySQL - с натяжкой.

Делай EAV, когда и если упрешься в производительность - появится кэширование и то или иное стороннее хранилище для поиска.

fixxxer написал(а):

Реляционные базы данных - это как раз Postgresql и Oracle. MySQL - с натяжкой.

Делай EAV, когда и если упрешься в производительность - появится кэширование и то или иное стороннее хранилище для поиска.

Нажмите для раскрытия...

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

1) очень геморройно работать со списком, в котором параметры в куче разных таблиц
2) если появятся подкатегории, у тебя получится дерево таблиц и тут ты вообще охренеешь
3) если понадобится изменить такую таблицу, alter table большой таблицы положит тебе сервер
4) если не вырастешь, и EAV будет хорошо работать, если вырастешь, кэширование и денормализация на EAV ложатся намного проще

18 млн записей в таблице - не самая большая проблема в жизни eav будет работать нормально даже без шардинга просто с нормальными индексами
это ж не 18 млн в день добавлять-удалять, это просто выборка

fixxxer написал(а):

1) очень геморройно работать со списком, в котором параметры в куче разных таблиц

Нажмите для раскрытия...

проблема, скорее, в связке параметров с категориями, а не с товарами

2) если появятся подкатегории, у тебя получится дерево таблиц и тут ты вообще охренеешь

Нажмите для раскрытия...

при интеграции со сторонними магазинами у него будут проблемы на порядок сложнее

3) если понадобится изменить такую таблицу, alter table большой таблицы положит тебе сервер

Нажмите для раскрытия...

с чего бы вдруг? ecommerce - не real-time, можно создать таблицу с нужной структурой и сделать в нее select into, засинкать триггером и ночью переименовать

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

Нажмите для раскрытия...

EAV будет хорошо работать даже если вырастет, сфинкс справится с условно любыми объемами

проблема, скорее, в связке параметров с категориями, а не с товарами

Нажмите для раскрытия...

ну как бы да, и я к тому, особенно с подкатегориями

при интеграции со сторонними магазинами у него будут проблемы на порядок сложнее

Нажмите для раскрытия...

у это вообще отдельный разговор

ночью переименовать

Нажмите для раскрытия...

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

EAV будет хорошо работать даже если вырастет, сфинкс справится с условно любыми объемами

Нажмите для раскрытия...

я-то уж догадываюсь вы, кстати, тогда мою искалку таки внедрили? UPD: посмотрел аяксы на поиск, вопрос снимается =)

Огромное всем спасибо!!!!!!!!!!