С того что BTREE всегда эффективно делит подмножества, а партишенинг не всегда, даже при эффективной природе ключа партишенинга количество подмножеств не всегда равно степени двойки.
SocFishing: Может есть возможность изначально разбить этот массив данных. Заведомо как-то переформировать. Например по алфавиту ключа и тд.
Партишенинг или шардинг всегда должен работать медленнее чем первичный ключ, даже для ключа типа BTREE не говоря о ключе HASH. Если партишенинг работает быстрее ключа, с ключом точно что-то не так.
---------- Добавлено 28.03.2020 в 16:48 ----------
Dreammaker: оговорка используется fts в постгре
FTS я вообще делаю на сфинксе, пока минусов не заметил.
В общем я уже решил. Полную структуру буду хранить в Монго, а для решения изначальной проблемы сделаю отдельную таблицу из id, value и буду ее хранить в MariaDB в таблице типа Memory.
danforth: Я не думаю что там просто так char(32), скорее всего md5 хранят.
Там де-факто только циферки, но trailing zero имеют значения, то есть 00234 и 000234 это два разных айдишника. Потому тип данных сделан ascii_bin. Длина действительно может быть разной, от 5 до 32 цифер, но я не понимаю чем varchar в этом случае лучше чем char(32)
---------- Добавлено 28.03.2020 в 14:16 ----------
danforth: если данные в таблицы выбираются только по ключу (т.е. нет range запросов), можете вынести все в Redis
Не хочется плодить зоопарк сервисов. И так уже есть Maria, Postgre и Mongo, только редиса не хватает...
---------- Добавлено 28.03.2020 в 14:20 ----------
danforth: Вангую что больше всего времени уходит на sending data, но тем не менее.
MariaDB [odnodata]> SHOW PROFILE FOR QUERY 1;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000021 |
| Waiting for query cache lock | 0.000007 |
| init | 0.000005 |
| checking query cache for query | 0.000032 |
| checking permissions | 0.000007 |
| Opening tables | 0.000016 |
| After opening tables | 0.000006 |
| System lock | 0.000006 |
| Table lock | 0.000007 |
| Waiting for query cache lock | 0.000029 |
| init | 0.000038 |
| optimizing | 0.000020 |
| statistics | 0.019021 |
| preparing | 0.000011 |
| Unlocking tables | 0.000018 |
| executing | 0.000006 |
| Sending data | 0.000033 |
| end | 0.000006 |
| query end | 0.000019 |
| closing tables | 0.000025 |
| Unlocking tables | 0.000010 |
| freeing items | 0.000009 |
| updating status | 0.000006 |
| Waiting for query cache lock | 0.000004 |
| updating status | 0.000021 |
| Waiting for query cache lock | 0.000005 |
| updating status | 0.000004 |
| storing result in query cache | 0.000029 |
| cleaning up | 0.000005 |
+--------------------------------+----------+
На одном запросе по-моему ничего видно не будет, это статистику на 1000 надо собирать.
---------- Добавлено 28.03.2020 в 14:25 ----------
Anamnado: делать базу распределенной. (реляционной)
То что вы описываете ниже по тексту называется шардинг.
Anamnado: работают уже с Оракл
Оракл это куча бабла и достаточно специфические полезные функции.
Anamnado: он для больших БД и разрабатывался
2кк записей и таблица 3.5Гб это совсем не "большие БД".
SocFishing: Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL.
Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.
SocFishing: Если вам нужно читать ключ - значение
Нужно ключ-значение, но я пока что сделаю отдельную таблицу id, value в MariaDB и буду держать ее в памяти. Не хочу разбираться как (и умеет ли) Mongo держать таблицы в памяти.
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE the_table const PRIMARY PRIMARY 96 const 1
drDaemon: На запрос и структуру таблицы взглянуть бы
Запрос:
SELECT id, value FROM the_table WHERE id='dfghekagr'
Структура длинная, лень красиво постить. 22 поля в общей сложности, типов INT, FLOAT и CHAR(n). Подробности разве могут иметь значение если row type FIXED?
Jet D.: Запрет индексации влияет только на вывод в поисковых результатах
Во многих случаях и на это не влияет. У меня были тысячи страницы "проиндексировано несмотря на запрет в robots.txt" пока не стал ставить запрет в meta robots непосредственно на странице - вот такой запрет работает.
---------- Добавлено 24.03.2020 в 23:08 ----------
Jet D.: И гуглоботы уже давно js обрабатывают, и данных с гуглобраузеров есть в избытке.
Тут палка о двух концах. Если редирект сделан просто, как подстановка в location значения, которое в явном виде есть где-то в коде страницы, та такой редирект гугл может считать как простую индексируемую ссылку. А если посложнее, то он именно видит разницу между тем что вычислил и тем что получает с браузеров и считает такое поведение клоакингом. В общем я бы js категорически не рекомендовал бы. К тому же редиректы через js могут блокировать плагины в браузерах.
Не рассчитывайте что удастся добыть хоть что-то стоящее.
С чего вы это взяли?
С того что BTREE всегда эффективно делит подмножества, а партишенинг не всегда, даже при эффективной природе ключа партишенинга количество подмножеств не всегда равно степени двойки.
Может есть возможность изначально разбить этот массив данных. Заведомо как-то переформировать. Например по алфавиту ключа и тд.
Партишенинг или шардинг всегда должен работать медленнее чем первичный ключ, даже для ключа типа BTREE не говоря о ключе HASH. Если партишенинг работает быстрее ключа, с ключом точно что-то не так.
---------- Добавлено 28.03.2020 в 16:48 ----------
оговорка используется fts в постгре
FTS я вообще делаю на сфинксе, пока минусов не заметил.
В общем я уже решил. Полную структуру буду хранить в Монго, а для решения изначальной проблемы сделаю отдельную таблицу из id, value и буду ее хранить в MariaDB в таблице типа Memory.
Я не думаю что там просто так char(32), скорее всего md5 хранят.
Там де-факто только циферки, но trailing zero имеют значения, то есть 00234 и 000234 это два разных айдишника. Потому тип данных сделан ascii_bin. Длина действительно может быть разной, от 5 до 32 цифер, но я не понимаю чем varchar в этом случае лучше чем char(32)
---------- Добавлено 28.03.2020 в 14:16 ----------
если данные в таблицы выбираются только по ключу (т.е. нет range запросов), можете вынести все в Redis
Не хочется плодить зоопарк сервисов. И так уже есть Maria, Postgre и Mongo, только редиса не хватает...
---------- Добавлено 28.03.2020 в 14:20 ----------
Вангую что больше всего времени уходит на sending data, но тем не менее.
MariaDB [odnodata]> SHOW PROFILE FOR QUERY 1;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000021 |
| Waiting for query cache lock | 0.000007 |
| init | 0.000005 |
| checking query cache for query | 0.000032 |
| checking permissions | 0.000007 |
| Opening tables | 0.000016 |
| After opening tables | 0.000006 |
| System lock | 0.000006 |
| Table lock | 0.000007 |
| Waiting for query cache lock | 0.000029 |
| init | 0.000038 |
| optimizing | 0.000020 |
| statistics | 0.019021 |
| preparing | 0.000011 |
| Unlocking tables | 0.000018 |
| executing | 0.000006 |
| Sending data | 0.000033 |
| end | 0.000006 |
| query end | 0.000019 |
| closing tables | 0.000025 |
| Unlocking tables | 0.000010 |
| freeing items | 0.000009 |
| updating status | 0.000006 |
| Waiting for query cache lock | 0.000004 |
| updating status | 0.000021 |
| Waiting for query cache lock | 0.000005 |
| updating status | 0.000004 |
| storing result in query cache | 0.000029 |
| cleaning up | 0.000005 |
+--------------------------------+----------+
На одном запросе по-моему ничего видно не будет, это статистику на 1000 надо собирать.
---------- Добавлено 28.03.2020 в 14:25 ----------
А вообще, сделайте пожалуйста
{
"query_block": {
"select_id": 1,
"table": {
"table_name": "the_table",
"access_type": "const",
"possible_keys": ["PRIMARY"],
"key": "PRIMARY",
"key_length": "32",
"used_key_parts": ["id"],
"ref": ["const"],
"rows": 1,
"filtered": 100
}
}
Если char 32 почему 96? реально нужны ключи в mb-кодировке?..
Не нужны, вчера уже исправил, быстрее не стало.
key_buffer_size что показывает?
Глобальный 16777216
Но я уже сделал отдельный CACHE INDEX на эту таблицу:
SET GLOBAL the_cache.key_buffer_size = 2000000 * 32
CACHE INDEX the_table IN the_cache
И тоже не помогло.
сортировка есть по какому-то полю?
Сортировки нет
делать базу распределенной. (реляционной)
То что вы описываете ниже по тексту называется шардинг.
работают уже с Оракл
Оракл это куча бабла и достаточно специфические полезные функции.
он для больших БД и разрабатывался
2кк записей и таблица 3.5Гб это совсем не "большие БД".
Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL.
Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.
Если вам нужно читать ключ - значение
Нужно ключ-значение, но я пока что сделаю отдельную таблицу id, value в MariaDB и буду держать ее в памяти. Не хочу разбираться как (и умеет ли) Mongo держать таблицы в памяти.
Explain запроса делали ?
На запрос и структуру таблицы взглянуть бы
Запрос:
SELECT id, value FROM the_table WHERE id='dfghekagr'
Структура длинная, лень красиво постить. 22 поля в общей сложности, типов INT, FLOAT и CHAR(n). Подробности разве могут иметь значение если row type FIXED?
Представим простую ситуацию - сделка не регистрируется, а продавец вдруг внезапно умирает
А если покупатель внезапно умирает?
Запрет индексации влияет только на вывод в поисковых результатах
Во многих случаях и на это не влияет. У меня были тысячи страницы "проиндексировано несмотря на запрет в robots.txt" пока не стал ставить запрет в meta robots непосредственно на странице - вот такой запрет работает.
---------- Добавлено 24.03.2020 в 23:08 ----------
И гуглоботы уже давно js обрабатывают, и данных с гуглобраузеров есть в избытке.
Тут палка о двух концах. Если редирект сделан просто, как подстановка в location значения, которое в явном виде есть где-то в коде страницы, та такой редирект гугл может считать как простую индексируемую ссылку. А если посложнее, то он именно видит разницу между тем что вычислил и тем что получает с браузеров и считает такое поведение клоакингом. В общем я бы js категорически не рекомендовал бы. К тому же редиректы через js могут блокировать плагины в браузерах.