Не рассчитывайте что удастся добыть хоть что-то стоящее.
С того что BTREE всегда эффективно делит подмножества, а партишенинг не всегда, даже при эффективной природе ключа партишенинга количество подмножеств не всегда равно степени двойки.
Партишенинг или шардинг всегда должен работать медленнее чем первичный ключ, даже для ключа типа BTREE не говоря о ключе HASH. Если партишенинг работает быстрее ключа, с ключом точно что-то не так.---------- Добавлено 28.03.2020 в 16:48 ----------
FTS я вообще делаю на сфинксе, пока минусов не заметил.
В общем я уже решил. Полную структуру буду хранить в Монго, а для решения изначальной проблемы сделаю отдельную таблицу из id, value и буду ее хранить в MariaDB в таблице типа Memory.
Там де-факто только циферки, но trailing zero имеют значения, то есть 00234 и 000234 это два разных айдишника. Потому тип данных сделан ascii_bin. Длина действительно может быть разной, от 5 до 32 цифер, но я не понимаю чем varchar в этом случае лучше чем char(32)---------- Добавлено 28.03.2020 в 14:16 ----------
Не хочется плодить зоопарк сервисов. И так уже есть Maria, Postgre и Mongo, только редиса не хватает...---------- Добавлено 28.03.2020 в 14:20 ----------
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
}
Не нужны, вчера уже исправил, быстрее не стало.
Глобальный 16777216
Но я уже сделал отдельный CACHE INDEX на эту таблицу:
SET GLOBAL the_cache.key_buffer_size = 2000000 * 32
CACHE INDEX the_table IN the_cache
И тоже не помогло.
Сортировки нет
То что вы описываете ниже по тексту называется шардинг.
Оракл это куча бабла и достаточно специфические полезные функции.
2кк записей и таблица 3.5Гб это совсем не "большие БД".
Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.
Нужно ключ-значение, но я пока что сделаю отдельную таблицу 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
Запрос:
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 ----------
Тут палка о двух концах. Если редирект сделан просто, как подстановка в location значения, которое в явном виде есть где-то в коде страницы, та такой редирект гугл может считать как простую индексируемую ссылку. А если посложнее, то он именно видит разницу между тем что вычислил и тем что получает с браузеров и считает такое поведение клоакингом. В общем я бы js категорически не рекомендовал бы. К тому же редиректы через js могут блокировать плагины в браузерах.
