мускуль innodb

Инно я не помню

кстати о файлах и прочих блобах, стоит ли вынести их в отдельную таблицу?

Стоит, если делаешь select с полем blob или text, то результат в кеш не сохранится

не делаю

В базу,

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

особенно если файлов много и они мелкие

Разбивай файлы на поддериктории и храни путь до них

ну хз, это мне в базу лезть за путем, потом ещё сам файл тыркать

а так по идее сразу

Тоже не сразу

Зато файл будет отдавать nginx, а не MySQL

не, мне его не просто отдать надо, а ещё подправить

если бы всё так просто было :)

файлов 500к +

а так по идее сразу

До слез просто

Блоб ему база сразу отдаст. Да еще подправит налету. А между делом заварит чаю и наделает бутеров и все в один такт проца видимо ?

ну на сколько мне известно торрент трекеры, например, хранят файлы в базе

а не в фс

И феи с эльфами и птички из леса с песнями. Кто пересмотрел мультиков Диснея?

ну на сколько мне известно торрент трекеры, например, хранят файлы в базе

Ыыыы жги еще

сами торрент файлы

а не раздачи

в среднем файл 100 Кб

СУБД не очень хорошо ворочают блобы. в большистве случаев сходить в фс быстрее.

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

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

3 уровня по 3 символа на директорию

3 уровня по 3 символа на директорию

ну на том же рутрекере 1,653,212 _активных_ раздач

пффф...

это выходит 60к файлов на директорию

это уже медленно для фс

100 директорий на каждый уровень 10к файлов в директорию. Уже получаем 10 млн. файлов

ну на том же рутрекере 1,653,212 _активных_ раздач

это копейки, на 256 каталогов получается по 7 тысяч файлов в каталоге

хм, видимо криво посчитал

Берём PK, создаём структуру каталогов, кладём туда файл. Например, PK-13579, путь к файлу /1/3/5/7/9/13579

меньше 10к на директорию ещё приемлимо

Берём PK, создаём структуру каталогов, кладём туда файл. Например, PK-13579, путь к файлу /1/3/5/7/9/13579

слишком большую вложенность тоже вредно делать

Можно играться разрядностю, например, /01/35/79/13579

Или /135/759/13579

слишком большую вложенность тоже вредно делать

Странное заявление. Чем вредно?

Странное заявление. Чем вредно?

Тем что у тебя будет каталог с 1 файлом

Тем что у тебя будет каталог с 1 файлом

И что?

ну на сколько мне известно торрент трекеры, например, хранят файлы в базе

Вообще-то их генерят

Привет, Mysql query error: (1117) Too many columns (400) вот такую ошибку получаю, какое ограничение у MySQL есть на количество свойств в таблице?

в данной таблице в каждой строке заполнено максимум 8-10 столбцов, остольное NULL

Но колонка же есть, причем 400 штук, я так понимаю ?

Привет, Mysql query error: (1117) Too many columns (400) вот такую ошибку получаю, какое ограничение у MySQL есть на количество свойств в таблице?

А ты уверен, что 400 колонок в таблице — это GOOD ?

да чего вы взяли что их там 400? :))

их там уже под 1000

значит 1117

и это ограничение InnoDB

да не уверен конечно

а ты в курсе, как хранятся данные?

думаю это совсем не гуд при такой заполняемости

такую таблицу генерит самописный компонент для Битрикса

это не ответ

в смысле как хранятся данные?

в прямом

вы понимаете, что у вас чтение и запись оверхеад на пустом месте

их там уже под 1000

Даже для аналитических бд (колоночных), в которых данные расладываются в ширину колонок дохрена.

с оверхедом понятно, поэтому буду выпиливать эту радость

Даже для аналитических бд (колоночных), в которых данные расладываются в ширину колонок дохрена.

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

а такое получилось потому что в интернет магазие более 1 млн товаров, каждый товар имеет по 8-10 свойств, каждое свойство это один столбец, свойства конечно одинаковые для групп, но и групп то нагенерели уже мама не горюй

такое получилось, потому что разработчик долбаеб

ERROR: S client not available

я гдето читал что есть БД которые быстры как зар за счет стобцовой организации данных

я так понимаю это не к mysql

буквально недавно обсуждали с одним, как такие вещи делают

https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

я так понимаю это не к mysql

Точно!

их там уже под 1000

Так ещё хуже!

да чего вы взяли что их там 400? :))

Я тебе скажу, что реальное ограничение по числу полей в словаре не так уж и важно. А вот ограничение общей длины записи более быстро играет.

такую таблицу генерит самописный компонент для Битрикса

ВЫКИНЬ ЭТУ ГАДОСТЬ!

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

я гдето читал что есть БД которые быстры как зар за счет стобцовой организации данных

Вряд ли ты будешь рад держать магазин на колоночной СУБД.... Да и не нужно. Колоночные нужны при объёмах от миллиарда записей в таблице.

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

Нужно просто нормализовать данные.

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

Вряд ли ты будешь рад держать магазин на колоночной СУБД.... Да и не нужно. Колоночные нужны при объёмах от миллиарда записей в таблице.

Амазон плачет в уголку от умиления

Амазон плачет в уголку от умиления

вот только мы как правило не амазон и не гугл)

вот только мы как правило не амазон и не гугл)

Это было очевидно по наличию 1000 колон

https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

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

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

я как пример, а не панацею принес

я как пример, а не панацею принес

Я понимаю

А колоночные бд рулят. Просто мало кто понимает как их пользовать. Нагородят 100500 колонок а потом говорят что у них данные которые не могут быть нормализованы.

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

сравнивать их нет смысла, как и объединять

всем привет!!! нужна помощь

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

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

ох эти собеседования

А колоночные бд рулят. Просто мало кто понимает как их пользовать. Нагородят 100500 колонок а потом говорят что у них данные которые не могут быть нормализованы.

Для OLTP-то ДАААААА РУЛЯТ НЕМЕРЯННО!

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

Я же говорю, ПОСЫЛАЙ ЭТИХ ДЕБИЛОВ!

Плохая задача, идиотская постановка, ничего не проверяет.

Для OLTP-то ДАААААА РУЛЯТ НЕМЕРЯННО!

Это сарказм?

Нет, это не сарказм.