@etojemph Проще и легче, наверное, на языке, который поддерживает автоматическую сборку мусора и не заставляет программиста думать о том, а удалил ли он объект до или после его использования. Ни C, ни C++ под это описание не подходят. Работать с сетью в наше время можно и на JavaScript.
Вот если PHP будет лидировать в CPU-bound задачах, я крайне удивлюсь. Там такое количество добра вокруг данных и вызовов методов обернуто, что лидировать он не может ни при каких условиях.
@Trrrrr Мой пойнт был не в том, что у человека тормозит аллокатор. А в том, что причины, по которым C++ должен быть быстрее C# совершенно не очевидны. Как пример я привел различие в алгоритмах работы стандартного аллокатора C# и стандартного же аллокатора C++, ни слова не говоря ни и чем другом.
@Trrrrr А в каком именно утверждении я ошибаюсь? В том, что у C# аллокатор эффективнее - ну, докажите, что это не так. А больше я ничего и не утверждал, я спросил, почему это C++ должен быть быстрее.
@bejoy Этот конкретный запрос обратится только к первой, а вообще хэш на то и хэш, чтобы быть равномерным. Партицировать имеет смысл по ключу, доступ к которому имеет неравномерный характер. Ну, либо если шпинделей в машине более одного, как я уже говорил.
@bejoy Я ж написал - если обращения происходят равномерно ко всем партишнам, прироста не будет. Если партишнинг сделан, допустим, по дате, и в старые записи (допустим, прошлый месяц или начало года) никто не ходит - конечно, все запросы будут попадать в одну партицию. Это даст прирост.
@bejoy партицировать имеет смысл, только если в сервере есть несколько физических дисков, и каждая партиция лежит на своем. В противном случае, если обращения происходят равномерно ко всем партишнам, то все индексы все равно так же находятся в памяти, а данные - так же на одном диске. Прироста это не даст.
@Melkij Про бинарную кашу - это неправда, не пугайте коллегу. Правда в том, что время восстановления MyISAM таблицы после сбоя пропорционально ее размеру, тогда как для InnoDB оно пропорционально размеру транзакшн лога, который больше 128M ставить все равно смысла не имеет.
@bejoy именно для этого я предлагаю имена все-таки хранить и сравнивать в запросе и хэш, и само имя. Второй вариант - хранить два разных хэша (4 и 4 байта), а индекс строить только по одному из них.
Хэш надо делать в 4 байта, конечно же. Строку - в инт. Имеется в виду не md5 хэш, а, скажем, первые 4 байта md5 хэша.
Стремиться к фиксированному размеру записи я не вижу никакого смысла и не встречал никаких рекомендаций так делать.
Да, если имена не нужны - можно их заменять на первые 4 байта их md5 хэша и хранить integer вместо строки.
RTS/CTS помогает в любом случае, спасает от hidden node problem, например. WDS я не использую - все три точки у меня разные и имеют разные прошивки, WDS в таких условиях сделать просто невозможно.
