|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
знаю что это плохо, но нужно примерное количество до 500, использую марию приоритет скорость выборки какое решение посоветуете? возможно использовать спец базу? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2020, 14:13 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top какое решение посоветуете? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2020, 16:41 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
брать постгрю. брать EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2020, 17:46 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top знаю что это плохо, но нужно примерное количество до 500, использую марию приоритет скорость выборки какое решение посоветуете? возможно использовать спец базу? кол-во, в том числе и колонок, не показатель для ускорения выборки используют индексы. Если point select (возвращающие 1 строку) идут по индексу, то хоть 100500 колонок, от чего ему тормозить? объем пересылаемых данных, разумеется будет в 500 раз больше, чем при одной колонке, но если задача требует столько данных, что Вы можете поделать ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2020, 18:07 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top, как уже выше неявно уточнили - смотря какие поля и какие запросы. Если 500 полей рандомно участвуют в условии выборки - это нереально построить кучу индексов. выкладывайте суть данных, и суть запросов... вижу предыдущие посты но так и не понял результатов ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2020, 21:07 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
Alex_Ustinov, для примера- список товаров, у каждого товара есть характеристики, при этом для разных магазинов свои значения характеристик например длина_а,длина_б,длина_в,цена_а,цена_б,цена_в,вес_а,вес_б,вес_в магазинов много, и характеристик много поиск может быть по цена_а>1 и цена_б>5 или по цена_б>5 и цена_в>10, или добавится в условие вес_а и вес_б одной колонкой точно не обойтись структуру менять не получится,там много на ней завязано,да и работы по переделке будет очень много поэтому нужно выбрать оптимальное решение для хранения и выборки, возможны варианты таблиц в памяти ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 11:02 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
И в чем проблема? какая-то преждевременная оптимизация. IMHO ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 12:03 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top знаю что это плохо, но нужно Это плохо и не нужно. zizi_top какое решение посоветуете? Нужен специалист. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 12:18 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top магазинов много, и характеристик много Посмотри схему бд в opencart. zizi_top структуру менять не получится,там много на ней завязано,да и работы по переделке будет очень много Очень грустно за вас. Надо было нанимать специалиста. zizi_top поэтому нужно выбрать оптимальное решение для хранения и выборки, возможны варианты таблиц в памяти Делали херак-херак и в продакшон, поэтому теперь только костыли, боль и страдания. Такая вот она, суровая правда жизни. А вы думаете, мы тут просто так срачи устраиваем? Нет, не просто. Хорошо спроектированная система имеет хоть какие-то шансы на нормальную работу и сопровождение в отличии от спроектированной через жопу. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 12:23 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top для примера- список товаров, у каждого товара есть характеристики, при этом для разных магазинов свои значения характеристик например длина_а,длина_б,длина_в,цена_а,цена_б,цена_в,вес_а,вес_б,вес_в магазинов много, и характеристик много..... Вашу систему не знаю, но для OeBS - Oracle e-Business Suite, список товаров это таблица Items. С другой стороны, то что Вы описываете (разные характеристики для разных групп товаров), очень похоже на приложение e-Commerce. Насколько я помню, там группы товаров, их атрибуты и классификация - в отдельных таблицах. 1. В любом случае, это справочник. Т.е. данных там по определению много быть не может. (много, по отношению ко всей системе). 2. Если "поисковые характеристики" сильно замусоривают основную таблицу и нужны только в одном модуле (например в Web-магазине) и есть опасения, что они существенно замедлять остальные модули (склад, продажи, закупки, где эти характеристики даром не нужны) - то лично я бы вынес их в отдельную таблицу со связью 1=1. Поскольку таблицы можно объединять во View, то изменения системы минимальны (не знаю, насколько MySQL эффективно работает со View), т.е. разделить можно в любой момент. 3. Насколько сильно замедляет и нужна ли оптимизация - вопрос открытый. Т.к. см. п.1. Чего я бы точно не делал: 1. Не расматривал EAV как "хорошее решение" 2. Не делил бы таблицу по типам магазинов/группам товаров. Т.к. это сильно усложнит поиск и значительно его замедлит. А вот приемушеств лично я не вижу. IMHO Не специалист в MySQL, больше Oracle. На всякий случай посмотрел, что про ограничения говорит документация. https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html#row-size-limits Column Count Limits MySQL has hard limit of 4096 columns per table, but the effective maximum may be less for a given table. The exact column limit depends on several factors: The maximum row size for a table constrains the number (and possibly size) of columns because the total length of all columns cannot exceed this size. See Row Size Limits. The storage requirements of individual columns constrain the number of columns that fit within a given maximum row size. Storage requirements for some data types depend on factors such as storage engine, storage format, and character set. See Section 11.7, “Data Type Storage Requirements”. Storage engines may impose additional restrictions that limit table column count. For example, InnoDB has a limit of 1017 columns per table. See Section 15.22, “InnoDB Limits”. For information about other storage engines, see Chapter 16, Alternative Storage Engines. Functional key parts (see Section 13.1.15, “CREATE INDEX Statement”) are implemented as hidden virtual generated stored columns, so each functional key part in a table index counts against the table total column limit. Row Size Limits The maximum row size for a given table is determined by several factors: The internal representation of a MySQL table has a maximum row size limit of 65,535 bytes, even if the storage engine is capable of supporting larger rows. BLOB and TEXT columns only contribute 9 to 12 bytes toward the row size limit because their contents are stored separately from the rest of the row. The maximum row size for an InnoDB table, which applies to data stored locally within a database page, is slightly less than half a page for 4KB, 8KB, 16KB, and 32KB innodb_page_size settings. For example, the maximum row size is slightly less than 8KB for the default 16KB InnoDB page size. For 64KB pages, the maximum row size is slightly less than 16KB. See Section 15.22, “InnoDB Limits”. If a row containing variable-length columns exceeds the InnoDB maximum row size, InnoDB selects variable-length columns for external off-page storage until the row fits within the InnoDB row size limit. The amount of data stored locally for variable-length columns that are stored off-page differs by row format. For more information, see Section 15.10, “InnoDB Row Formats”. Different storage formats use different amounts of page header and trailer data, which affects the amount of storage available for rows. For information about InnoDB row formats, see Section 15.10, “InnoDB Row Formats”. For information about MyISAM storage formats, see Section 16.2.3, “MyISAM Table Storage Formats”. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 12:41 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, У него выбора особо нет. Или быстро решительно приделать eav, или страдать со своей таблицей в 500 строк, или по таблице на каждый тип товара. Там у них поди еще и дельфи вместо фронтенда, так что даже просто всунуть eav не получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2020, 03:51 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
crutchmaster или страдать со своей таблицей в 500 строк столбцов Сначала надо, что бы автор уточнил, в чем же именно у него страдание. А есть ли вообще проблема? Посмотрел документацию, например в InnoDB NULL в данных не хранятся (пустая колонка занимает 1 байт в заголовке строки, место под данные не резервируется). Т.ч. от пустых колонок в InnoDB оверхид не такой уж и большой. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2020, 15:24 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
изначально вопрос касался совета по выбору базы данных или типа таблицы чтобы при прочих равных скорость на выборку была самая высокая ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2020, 18:36 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
Не бывает "при прочих равных" Бывает OLTP нагрузка, бывает OLAP...... тогда еще можно разсуждать про "спец базу" Ну а так - переходите на Oracle Exadata и будет Вам счастье ))) "при прочих равных" явно будет быстрее MySQL ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2020, 18:42 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Сначала надо, что бы автор уточнил, в чем же именно у него страдание. В прошлом треде у него тормозили самые элементарные выборки на детском размере таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2020, 06:50 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top изначально вопрос касался совета по выбору базы данных или типа таблицы чтобы при прочих равных скорость на выборку была самая высокая Переделай всё на какой-нибудь nosql key-value ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2020, 06:51 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Ну а так - переходите на Oracle Exadata и будет Вам счастье ))) Там а архитектурой всё очень плохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2020, 06:52 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
crutchmaster В прошлом треде.... Тут программист нужен ( C ) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2020, 09:55 |
|
таблица в которой много колонок
|
|||
---|---|---|---|
#18+
zizi_top изначально вопрос касался совета по выбору базы данных или типа таблицы чтобы при прочих равных скорость на выборку была самая высокая 1. Перенести данные в "подчиненную" таблицу. 2. Всего лишь переделать 3 запроса - Insert (добавление свойства объекта), Update, Delete. 3. Переделать остальные Select-ы (на данные не влияют никак) Это страшно для "мозга", но для "кармы" очень даже положительно ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2020, 11:37 |
|
|
start [/forum/topic.php?fid=47&msg=39994386&tid=1828392]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
145ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 264ms |
0 / 0 |