|
|
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
AkinaCygapb-007и только если нет обоих – искуственно создается автонумератор. Вы неверно прочитали мануал. Этот "внутренний автонумератор" в таблицах InnoDb есть ВСЕГДА. И ещё одно - доступ к нему получить НЕЛЬЗЯ. В принципе.Позвольте все же не согласиться... http://dev.mysql.com/doc/refman/5.6/en/innodb-table-and-index.html 14.2.3.12.2. Clustered and Secondary Indexes Every InnoDB table has a special index called the clustered index where the data for the rows is stored. Typically, the clustered index is synonymous with the primary key. To get the best performance from queries, inserts, and other database operations, you must understand how InnoDB uses the clustered index to optimize the most common lookup and DML operations for each table. When you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index. Define a primary key for each table that you create. If there is no logical unique and non-null column or set of columns, add a new auto-increment column, whose values are filled in automatically. If you do not define a PRIMARY KEY for your table, MySQL locates the first UNIQUE index where all the key columns are NOT NULL and InnoDB uses it as the clustered index. If the table has no PRIMARY KEY or suitable UNIQUE index , InnoDB internally generates a hidden clustered index on a synthetic column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order. там же, далее How Secondary Indexes Relate to the Clustered Index All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index. If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 09:30:22 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Эх, надо было еще "If" выделить жирным красным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 09:31:33 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
На самом деле я влип в этот флейм из-за вот этого поста:МихаилКAkinaА каким боком тут ваш этот индекс? Используемый индекс (который PRIMARY KEY (`ID`) ) - он вообще кластерный и места на диске не занимает Да, так и оказалось. Удалил второй индекс и действительно ноль. Так какое резюме? 50 млн - чепуховый объем и мне даже не париться на этот счет? Текущий размер таблицы на диске 53.6Мб, в 50 раз больше - примерно 2.5Гб.Как можно удалять индекс, по которому идет первичный поиск данных в таблице? Или вы хотите сказать, что в таблицах USERS и OBJECTS записан map_id=777 для обновляемой строки MAP? Более того, этот индекс (вроде бы) должен быть хотя бы UNIQUE, если уж не PRIMARY KEY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 09:39:27 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Позвольте все же не согласиться... Наполовину позволяю. Чуть ниже: авторIf no primary key was defined for a table, each clustered index record also contains a 6-byte row ID field. Причём на самом деле требуется или primary, или unique key - простой key не подходит. Эксперимент: небольшая таблица, имеется уникальное по содержимому поле ID. Если создан уникальный (неважно, primary или просто unique) индекс на это поле - размер файла таблицы 448 кб. Если его нет вообще - размер файла таблицы 480 кб (добавлен тот самый 6-byte row ID field). Если индекс есть, но не указано, что он уникален - размер файла таблицы 560 кб (добавлен тот самый 6-byte row ID field, по нему построен кластерный индекс, а индекс по ID мотается сам по себе). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 10:03:14 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
AkinaCygapb-007Позвольте все же не согласиться... Наполовину позволяю. Чуть ниже: автор If no primary key was defined for a table, each clustered index record also contains a 6-byte row ID field. Причём на самом деле требуется или primary, или unique key - простой key не подходит. Эксперимент: небольшая таблица, имеется уникальное по содержимому поле ID. Если создан уникальный (неважно, primary или просто unique) индекс на это поле - размер файла таблицы 448 кб. Если его нет вообще - размер файла таблицы 480 кб (добавлен тот самый 6-byte row ID field). Если индекс есть, но не указано, что он уникален - размер файла таблицы 560 кб (добавлен тот самый 6-byte row ID field, по нему построен кластерный индекс, а индекс по ID мотается сам по себе).Перечитайте свою цитату Как это коррелирует с вашим же утверждением?AkinaCygapb-007и только если нет обоих – искуственно создается автонумератор. Вы неверно прочитали мануал. Этот "внутренний автонумератор" в таблицах InnoDb есть ВСЕГДА . И ещё одно - доступ к нему получить НЕЛЬЗЯ. В принципе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 10:07:36 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Как это коррелирует с вашим же утверждением?Наполовину. Или память немного подвела, или с того момента, когда написанное мной было верно, прошло много времени, и эти сведения устарели. Потому и поэкспериментировал немного, чтобы узнать, как оно сейчас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 10:12:49 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Не совсем точно:AkinaЕсли индекс есть, но не указано, что он уникален - размер файла таблицы 560 кб (добавлен тот самый 6-byte row ID field, по нему построен кластерный индекс, а индекс по ID мотается сам по себе).Индекс по ID "мотается" не "сам по себе", а в привязке к автоматически сгенерированному кластерному индексу (доступа к значениям которого действительно нет из SQL запроса:) ). И такова судьба каждого дополнительного индекса, независимо от того, сгенерирован кластерный индекс или указан разработчиком - "тянуть в себе" все поля, составляющие кластерный индекс :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 10:14:22 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
AkinaCygapb-007Как это коррелирует с вашим же утверждением?Наполовину. Ага-ага "она была немножко беременна" (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 10:17:53 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007с идеей пакетной обработки я не спорю, но ей ни в коей мере не противоречит фиксация изменений в базе не по надуманному «номеру строки», а по «родной» связке юзера и объекта, по которой, собственно, и была доставлена в обработку исправленная запись (то есть по «естественному первичному ключу»). Вы предлагаете мне завести дополнительный составной индекс по двум полям и искать по нему, хотя я УЖЕ знаю значение праймери кей. И что, я выиграю в скорости? Если да, я так сделаю, но я не понимаю, почему я должен выиграть в скорости. Может быть, объясните? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:01:23 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007, я так понимаю, Вы смотрите на данные с уровня БД. На самом деле, если смотреть на данные с уровня сервера приложения, то некоторые вещи выглядят иначе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:05:39 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
МихаилКCygapb-007с идеей пакетной обработки я не спорю, но ей ни в коей мере не противоречит фиксация изменений в базе не по надуманному «номеру строки», а по «родной» связке юзера и объекта, по которой, собственно, и была доставлена в обработку исправленная запись (то есть по «естественному первичному ключу»). Вы предлагаете мне завести дополнительный составной индекс по двум полям и искать по нему, хотя я УЖЕ знаю значение праймери кей. И что, я выиграю в скорости? Если да, я так сделаю, но я не понимаю, почему я должен выиграть в скорости. Может быть, объясните?Не совсем так... Я просто ну никак не могу понять - каким образом вы узнали ID. Вы так и не ответили на этот вопрос. Нет, понятно, что к моменту, когда данные отображаются в интерфейсе, вы уже знаете все ID, - но по какому критерию они отбираются для отображения? Ну, или представлены в виде порции данных, соответствующей заданным критериям отбора, если так яснее смысл вопроса... Выше я высказал свою версию - но вы ни согласились с ней, ни опровергли... PS хотя если вы чохом закачиваете все-все данные в память, и уже в памяти смотрите, какие user_id и object_id заданы в фильтре, то тогда в базе индекс по этим полям, конечно, не нужен. Но нужно много памяти :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:13:24 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
МихаилКCygapb-007, я так понимаю, Вы смотрите на данные с уровня БД. На самом деле, если смотреть на данные с уровня сервера приложения, то некоторые вещи выглядят иначе.Да, в этом Вы правы... Пусть тормозит БД - это не проблема приложения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:14:44 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Пропустил по невнимательности, извиняюсь...МихаилКCygapb-007Но на вопрос, откуда в модели возник номер 777 — вы так и не ответили :) Сейчас модель считывается из БД перед обработкой пакета запросов. В дальнейшем планируется использовать мемкеш, чтобы считывать ее один раз при коннекте и затем лазить в бд только с апдейтами. Естественно, про негарантированное хранение в мемкеше все в курсе.Сервер базы, сервер приложений, куча пользователей, работающих с моделью данных, представленной на сервере приложений. Сервер приложений закачивает в себя все-все что есть в сервере базы, далее все пользователи работают только с сервером приложений, при валидности транзакции в модели она фиксируется в сервере базы данных. Тогда понятно, и конечно лишние индексы только утяжелят базу. Оптимальность фильтрации к серверу БД не имеет никакого отношения. Составные индексы в БД - вредны, в том числе ( 14695748 ) KEY `userID` (`userID`) Вопрос: а нафига в таком случае сервер базы (раз сервер приложений может хранить все-все "в себе") ? Хотя это снова не моя проблемы, вопрос снимается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 11:50:17 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Не совсем так... Я просто ну никак не могу понять - каким образом вы узнали ID. Вы так и не ответили на этот вопрос. Нет, понятно, что к моменту, когда данные отображаются в интерфейсе, вы уже знаете все ID, - но по какому критерию они отбираются для отображения? Ну, или представлены в виде порции данных, соответствующей заданным критериям отбора, если так яснее смысл вопроса... На самом деле, я ответил. Причем уже раза два или три. Я знаю все ID, потому что они есть в модели. Кстати, интерфейс и модель - вещи разные, даже не совсем понимаю, откуда всплыл этот "интерфейс", речь же не о сайте идет, а об игровом приложении. Общая логика такова. При инициализации юзера в игре из базы считываются все данные по юзеру, которыми заполняется класс User - это модель юзера. Данные модели сериализуются в json и отправляются на клиент для визуализации. Перед отправкой данных на клиент, модель в виде объекта сохраняется в хранилище мемкеш (memcache). Это позволит при следующих пакетных запросах со стороны клиента не лазить в базу за считыванием актуального состояния модели пользователя, а получать ее из мемкеша с фактически нулевыми накладными расходами (что такое memcache гуглим самостоятельно). Пакет, поступивший от клиента, прогоняется по модели и, если все в порядке, изменения накатываются на модель, записываются в базу (формируется пакет запросов update/insert/delete, которые отрабатываются на базе) а сама модель обновляется в мемкеше и цикл отработки пакетов запросов с клиента повторяется. В случае, если данные клиента и модели расходятся, обработка пакета, в котором это произошло, останавливается, на клиент отправляется ответ, что нужно обновление модели, клиент повторно запрашивает данные пользователя, модель заново считывается из базы и отправляется на клиент. Поскольку мемкеш не обеспечивает гарантированного хранения информации, то в случае, если при поступлении пакета от клиента модели в мемкеше нет, она так же заново считывается из базы. Как-то так, если общими словами. Данная схема имеет ряд существенных недостатков и на первый взгляд не обеспечивает гарантированной целостности данных (разве что заморочиться с обновлением модели в рамках одной транзакции), но для игровых приложений - вполне достаточно. ЗЫ. Соответственно, когда и я упомянул про работу с данными на уровне сервера приложения - я лишь имел в виду, что за счет организации данных и использования различных механизмов хранения информации можно существенно (по факту - в несколько раз) снизить нагрузку на базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 12:34:30 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Вопрос: а нафига в таком случае сервер базы (раз сервер приложений может хранить все-все "в себе") ? Нет, ну можно, конечно, хранить данные в текстовых файлах... Но если есть такой механизм, как база данных - чего бы его не использовать? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 12:40:35 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Сервер приложений закачивает в себя все-все что есть в сервере базы, далее все пользователи работают только с сервером приложений, при валидности транзакции в модели она фиксируется в сервере базы данных. Вот тут ошибка. Не всю информацию, естественно, а только постоянную информацию по объектам/айтемам (она подкачивается по мере необходимости) и данные по активным пользователям в приложении. Как только пользователь выходит из приложения, его модель через некоторое время сбрасывается автоматически (если точнее - затирается другими данными) Cygapb-007Составные индексы в БД - вредны, в том числе (14695748) KEY `userID` (`userID`) Это теперь тоже составной индекс? :) Индекс по userID нужен, чтобы выдернуть из таблицы map объекты конкретного юзера. Кстати, что интересно, я так и не получил ответ на тот вопрос который изначально задавал. Перефразирую. Может ли кто-нибудь обеспечить на своей таблице innoDB в млн записей и больше апдейт одной конкретной записи за время, скажем, меньшее, чем 0.01 сек и, если да, то как он этого добивается (какое железо, какие настройки и т.д.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:00:13 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ. Все разлеглось по полочкам.МихаилКCygapb-007по какому критерию они отбираются для отображения?При инициализации юзера в игре из базы считываются все данные по юзеру , которыми заполняется класс User - это модель юзера.Повторюсь, вопрос возник после фразы об удалении индекса:МихаилКAkinaА каким боком тут ваш этот индекс? Используемый индекс (который PRIMARY KEY (`ID`) ) - он вообще кластерный и места на диске не занимает Да, так и оказалось. Удалил второй индекс и действительно ноль. Так какое резюме? 50 млн - чепуховый объем и мне даже не париться на этот счет? Текущий размер таблицы на диске 53.6Мб, в 50 раз больше - примерно 2.5Гб.Удаление индекса способствует ускорению считывания всех данных по юзеру из базы? OFFTOP:МихаилКинтерфейс и модель - вещи разные, даже не совсем понимаю, откуда всплыл этот "интерфейс", речь же не о сайте идет, а об игровом приложении. То есть у игрового приложения нет интерфейса?? В котором в той или иной форме отображаются данные, представленные в модели? Вопрос риторический ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:01:47 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Повторюсь, вопрос возник после фразы об удалении индекса Не-не :) Это я скопировал таблицу и удалил из нее индекс, чтобы проверить, как изменился размер индекса. В реальной таблице индекс остался. Но, как я понимаю, на апдейт он не влияет, только на инсерт при создании профиля нового пользователя. Cygapb-007То есть у игрового приложения нет интерфейса?? В котором в той или иной форме отображаются данные, представленные в модели? Вопрос риторический Тут другое. Когда сервер приложения представляет из себя сервер сайта, он сам формирует интерфейс и он доверяет тем данным, которые идут от интерфейса (ну, с соблюдением параметров авторизации, естественно). Есть разновидности, связанные с тем же ajax'ом, но сути это не меняет. Когда сервер входит в игровое приложение, он НЕ формирует интерфейс и НЕ доверяет данным поступающим от клиента. Поэтому никаких апдейтов по ID, поступающим от клиента быть, естественно не может. Без проверки по базе, модели или еще как. Поэтому я и говорю, что интерфейс тут ни при чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:17:03 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
Cygapb-007tanglirпропущено... Ага, особенно удобно после этого делать внешние ключи на записи такой таблицы К тому же (внезапно) в иннодб этот "автонумератор" всё равно есть, даже если вы его не создавали явно.Не совсем так. Ести есть PK, – то в качестве кластерного идекса используется именно он. Если PK нет, то принимается ближайший UNIQUE NOT NULL, и только если нет обоих – искуственно создается автонумератор. А про удобство создания внешних ключей на таблицу — вы невнимательны…Вообще-то я это и написал: если явно не создали, то будет системный; если явно создали, будет созданный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:21:18 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
И насчёт невнимательности поясните, а то я такой невнимательный, что всю тему до того поста заново перечитал и всё равно не заметил, что же я пропустил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:22:53 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
tanglirИ насчёт невнимательности поясните, а то я такой невнимательный, что всю тему до того поста заново перечитал и всё равно не заметил, что же я пропустил Прямо перед Вашим сообщением был пост 14699538 , с разносом в 1 час Cygapb-007МихаилК, С идеей пакетной обработки я не спорю, но ей ни в коей мере не противоречит фиксация изменений в базе не по надуманному "номеру строки", а по "родной" связке юзера и объекта, по которой, собственно, и была доставлена в обработку исправленная запись (то есть по "естественному первичному ключу"). Поле id имеет право на существование, если на эту таблицу есть ссылки в других (дочерних для нее) таблицах, но для обеспечения FK полю id достаточно auto_increment unique not null, оно не является первичным ключем таблицы в смысле поиска в ней данных со строны "родительских" таблиц.Впрочем, теперь это уже не актуально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 13:45:21 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
tanglir...tanglirК тому же (внезапно) в иннодб этот "автонумератор" всё равно есть, даже если вы его не создавали явно.... Вообще-то я это и написал: если явно не создали, то будет системный; если явно создали, будет созданный.Вообще-то вы писали про первичный ключ-автонумератор. Однако первичный ключ вовсе не обязан быть AUTO_INCREMENT (например, при отношении 1:0..1 для подчиненной таблицы) - и в этом случае никакой колонки "номер строки" (недоступной из SQL-запроса) для таблицы создано не будет, равно как не будет и автоматической нумерации строк этой таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:00:40 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
автори только если нет обоих – искуственно создается автонумератор. вы не правы. он есть всегда. http://dev.mysql.com/doc/refman/5.1/en/innodb-multi-versioning.html авторInternally, InnoDB adds three fields to each row stored in the database. ........................ A 6-byte DB_ROW_ID field contains a row ID that increases monotonically as new rows are inserted. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:02:37 |
|
||
|
Сохранение скорости апдейта при росте таблице
|
|||
|---|---|---|---|
|
#18+
ScareCrow, возражение - в первом сообщении второй страницы: 14700016 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2013, 14:04:47 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38364556&tid=1836256]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 345ms |

| 0 / 0 |
