Нужен совет: таблица с несколькими миллионами записей

asserte, тогда совсем непонятно. ну сделали бы индекс по первой букве. или вон по первым двум из md5 для равномерности.

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

10 млн мускуль выдержит

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

А таблицы в 1,5 млрд записей, потянет какая-то субд или придется разбивать на части?

а кто круче, Чак или Шварц?

глупые вопросы пошли.

почти любая субд потянет 1.5млрд записей. вопрос лишь как быстро она будет их обрабатывать.

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

Миллионы и миллиарды выдержит, вот только вопрос потянет ли железо.

ТС спросил в первом посте сколько времени будет отрабатываться запрос, ну если минут 5 + 15 гигабайт памяти нормально, то советуем не паниковать и дальше господа теоретики

Воткните список доменов обычными INSERT`ом в табличку (я кидал - было 1.2 ляма). После пятисотой тыщи начинались такие тормоза на запрос (AMD 3000+ 64 / 1.5 Gb Ram), что плакать хотелось. Это - обычный инсерт... Потом, когда пошел апдейт на булевы значения (в обработке/нет) пошли проблемы, когда два из 150 процессов тупо друг-дружку перекрывали. Лок, как таковой - не очень быстро, при таких объемах (это так кажется, что будет летать - можете для эксперимента дампик пульнуть в базу - увидите сами).

Сначала с таблицами колдовали - не удалось добиться приемлимого времени обработки запросов. Перешли на модификацию бизнес-логики (обработка запросов стэками) - не помогло. Приемлимых результатов добились только разбиением списка по первым буквам.

Собсно, вот так. А на счет реализации... ХЗ - под каждую задачу своё решение. :)

индексы были?

на таких объёмах удаление индексов значительно ускоряет добавление данных. Правда, если потом они всё же нужны, их нужно опять добавить - это всё же замедляет процесс. Но в целом ускоряет. :)

Камень сдохнеД.

10 человек онлайн для вас Дэдос))

В исходной таблице был primary_key id_domain с автоинкрементом. По нему и делались апдейты. По домену смысла не было делать индекс - выборок не было, в поиске не участвовало поле.

asserte, да хватит пугать лямами. полно народу и с бОльшими базами и нагенерить данные довольно легко. lock - это очень быстро. там нету никаких особенных накладных расходов.

вот блокировка таблицы на 5.5 млн записей :

mysql> set profiling=1;
Query OK, 0 rows affected (0.00 sec)

mysql> lock tables post write;
Query OK, 0 rows affected (0.02 sec)

mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
mysql> show profiles;
+----------+------------+------------------------+
| Query_ID | Duration   | Query                  |
+----------+------------+------------------------+
|        1 | 0.02673125 | lock tables post write | 
|        2 | 0.00017275 | unlock tables          | 
|        3 | 0.00005275 | show profiling         | 
+----------+------------+------------------------+
3 rows in set (0.00 sec)

mysql> show profile for query 1;
+--------------------+----------+
| Status             | Duration |
+--------------------+----------+
| starting           | 0.000042 | 
| Opening tables     | 0.000008 | 
| System lock        | 0.000003 | 
| Table lock         | 0.026656 | 
| query end          | 0.000009 | 
| freeing items      | 0.000006 | 
| closing tables     | 0.000003 | 
| logging slow query | 0.000002 | 
| cleaning up        | 0.000002 | 
+--------------------+----------+
9 rows in set (0.00 sec)

mysql> show profile for query 2;
+--------------------+----------+
| Status             | Duration |
+--------------------+----------+
| starting           | 0.000156 | 
| query end          | 0.000005 | 
| freeing items      | 0.000006 | 
| logging slow query | 0.000003 | 
| cleaning up        | 0.000004 | 
+--------------------+----------+
5 rows in set (0.00 sec)