Как описать алгоритм распределения?

Примерно так

Почему постоянно работает HDD независимо от ОС?

Спасибо, подожду пока он колом встанет.

Delphi - Как оптимизировать отрисовку синусоидальной кривой с количеством сэмплов более 1.000.000?

GDI+

Как вывести строки из базы данных по месяцам?

Правильно сформированный запрос отдаст ассоциативный массив в нужном формате, а не просто дамп таблицы. Вам нужен цикл прохода по массиву с процедурой echo?

Можно ли создать сайт, который нельзя закрыть по закону?

Вот вам постоянно обновляющийся сайт

<?php
	echo rand( );
?>

Сарказм, конечно, но, думаю, идея понятна.

Имеет ли смысл жертва размером ради производительности?

Хорошо. Для закрепления пройденного, правильно ли я понимаю, что следующий запрос будет обращаться ко всем партициям равномерно и смысла разбивки нет:

CREATE TABLE `user` (
`name` CHAR( 32 ) NOT NULL DEFAULT '',
`hash` TINYINT NOT NULL DEFAULT 0,
KEY ( `hash` )
)
PARTITION BY RANGE ( `hash` ) (
PARTITION `A` VALUES LESS THAN ( 100 ),
PARTITION `B` VALUES LESS THAN ( MAXVALUE ),
);

SELECT * FROM `user` WHERE `hash`=50 AND `name`='username';

Разве при этом запросе мускул не станет делать выборку только из записей, которые лежат в партиции "A"?

Имеет ли смысл жертва размером ради производительности?

Но даже если они лежат на одном носителе, хранилища у них буду разные, следовательно размеры каждого хранилища будут в четыре раза меньше целого. Это означает, что количество хранимых данных также будет в четыре раза меньше. А разве нет прямой связи межу количество данных в хранилище и скорость поиска?

Иносказательно выражаясь: у нас есть четыре ведра с грибами. Мы точно знаем, что только в третьем ведре грибы обеспечивают стабильный приход. Зачем нам тратить на время на первые два?

Имеет ли смысл жертва размером ради производительности?

Есть интересная идея:
допустим, есть два поля
`hash` INTEGER NOT NULL DEFAULT 0 COMMENT 'Account username hash',
`name` CHAR( 32 ) NOT NULL DEFAULT '' COMMENT 'Account username',
и, как вы предложили, поле `hash` хранит первые четыре байта хеша значения поля `name`. Мы значем, что щначение поля `hash` лежат в диапазоне 0..4294967295. Тогда, к примеры, можно партицировать таблицу следующим образом:
PARTITION BY RANGE ( `hash` ) (
PARTITION `hash.01` VALUES LESS THAN ( 1290000000 ), # * First part
PARTITION `hash.02` VALUES LESS THAN ( 2290000000 ), # * Second part
PARTITION `hash.03` VALUES LESS THAN ( 3290000000 ), # * Third part
PARTITION `hash.04` VALUES LESS THAN ( MAXVALUE ), # * Fourth part
)
По идее, это должно дать прирост производительности, так как выборка будет производиться блокам условно в четыре раза меньше.

Имеет ли смысл жертва размером ради производительности?

Интересный вариант, нужно попробовать. Спасибо.

Имеет ли смысл жертва размером ради производительности?

Здесь есть один сомнительный момент: в какую степень возводится шанс коллизии хеша, если для этого достаточно совпадения всего лишь первых четырех или даже восьми байт?

Имеет ли смысл жертва размером ради производительности?

1. InnoDB? Насколько сильным должен быть чих?
2. Каюсь, Field size: X * size_of_char, спасибо, не обратил внимание.

Имеет ли смысл жертва размером ради производительности?

1. Имеет ли смысл фиксированный размер записи? Стоит ли к нему стремиться в данном случае?

2. Извиняюсь за возможно глупый вопрос, но хэш — это та же строка, только изначально известной фиксированной длины. Так в чем же разница если
`name` CHAR( 32 ) NOT NULL DEFAULT '' COMMENT "Account username",
`hash` CHAR( 32 ) NOT NULL DEFAULT '' COMMENT "Account username md5 hash",

3. В таком случае можно вообще избавиться от прямого упоминания имен пользователей в таблице, оставив ли значения хэшей, поскольку для системы смысловая нагрузка имен не имеет значения. А это означает `name` CHAR( 32 ) NOT NULL DEFAULT '' COMMENT "Account username ms5 hash", что дает ответ на изначальный вопрос.

Правильно?

Где взять базу данных мобильных устройств?

Да, содержательно - именно то, что нужно. Но запрашивать информацию с чужого сервера каждый раз - в моей ситуации не очень хорошая идея. Вот бы у них была еще и оффлайн версия.