MySQL скорость: help

Разница действительно незначительная, но все таки она есть

Код:

CREATE TABLE `dm` (   `ip1` varchar(255) NOT NULL default '',   `ip2` varchar(255) NOT NULL default '',   KEY `ip1` (`ip1`,`ip2`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; CREATE TABLE `pentarh` (   `ip1` varchar(15) NOT NULL default '',   `ip2` varchar(15) NOT NULL default '',   KEY `ip1` (`ip1`,`ip2`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

После наполнения таблиц рандомными, но одинаковыми для обоих таблиц данными:

Код:

dm: Данные     33,944     Bytes Индекс    50,176    Bytes Всего    84,120    Bytes pentarh: Данные     33,800     Bytes Индекс    49,152    Bytes Всего    82,952    Bytes

Я все таки килобайт сэкономил

Pentarh писал:

Я все таки килобайт сэкономил

не скромничай, аж 1168 байта
матанализ упоминать не будем

ну, с днем программиста тебя !
и всех коллег тоже

keenza писал:

Код: string long2ip ( int proper_address ) int ip2long ( string ip_address ) Вопрос: я не понял зачем double? ip2long Integer возвращает

А то, что Integer в мускуле только положительный, а результат вовращаемый функцией ip2long() может быть отрицательным, поэтому надо юзать тип данных в базе double

С какого перепуга ИНТ вдруг только положительным стал ? unsigned убери, сразу отрицательным быть выучится.

Но все таки положительный лучше

Может комуто пригодится: я ip кодирую в 8-ми байтную строку. Каждые два байта - шестнадцатиричное представление октета. Очень удобно. Например IP 127.0.0.1 будет представлено как 7F000001. (Длина строки, кстати, всегда фиксированная)

имхо, в unsigned int конвертить проще, занимает места меньше + еще можно к такому полю применить операции сравнения.

Кстати, чего вы паритесь - знаковый или беззнаковый? То, что условно один бит принимают за знак - это сути не меняет. IP можно хранить и в том и в том варианте - разницы никакой нет.

Pentarh писал:

+ еще можно к такому полю применить операции сравнения.

и что ты тут сравнивать собрался? ip сравнивают по октетам (если не имеется ввиду полное совпадение, а, скажем проверка на отношение к како-либо подсети. а в случае полного совпадения любой вариант прокатит).

Последний раз редактировалось: stillen (13/09/06 в 21:58), всего редактировалось 1 раз

stillen писал:

Кстати, чего вы паритесь - знаковый или беззнаковый? То, что условно один бит принимают за знак - это сути не меняет. IP можно хранить и в том и в том варианте - разницы никакой нет.

Есть одна небольшая разница - операции сравнения будут работать некорректно. Если операции сравнения не нужны, тогда да.

Код:

string long2ip ( int proper_address ) int ip2long ( string ip_address )

честно говоря, несколько книг по ПХП прочитал, но такой функции не видел, спасибо.

stillen писал:

и что ты тут сравнивать собрался? ip сравнивают по октетам (если не имеется ввиду полное совпадение, а, скажем проверка на отношение к како-либо подсети. а в случае полного совпадения любой вариант прокатит).

Ну че, вполне реально применить такое вот сравнение:

111.111.111.0 < ip < 111.111.111.222

или такое

111.111.111.0 < ip < 111.111.222.0

прямо в майскл запросе (если айпи конвертнул в int unsigned)

Код:

function ip2long_unsigned ($ip) {    $l=ip2long($ip);    if ($l==-1) $l=0;    if ($l<0) $l += pow(2,32);    return $l; }

Crusader писал:

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

xreload писал:

4)Скрипт который добавляет несколько сотен тысяч записей в базу в сутки можешь смело удалять!

что-то вы мелко смотрите... ничего не вижу плохого в таком решении - если скрипт обрабатывает терабайты данных за сутки.

автор, есть хорошее решение, для того чтобы оптимизировать запросы по любым строкам. хранишь не реальную строку, а ее хэш, например md5 или sha, соответсвенно 32 и 40 байт, поиск по хэшу будет заметно быстрее, поскольку размер филда меньше. если тебе просто нужно проверить наличие - этого достаточно, если нужно получить строку, то делаешь еще одну таблицу, где varchar(255) без индекса, и внешний ключ на нее из таблицы с хэшами, по которому вытягиваешь реальное значение. существует мизерная вероятность, что у двух разных строк хэши совпадут, желательно для отсутствия багов ее разрумить.

удачи

Мелочные подходы, сотня тысяч записей - не так и много для нормального проекта.

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

Цитата:

мелочные подходы, мелко смотрите...

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

за хеш +1

Simplex писал:

автор, есть хорошее решение, для того чтобы оптимизировать запросы по любым строкам. хранишь не реальную строку, а ее хэш, например md5 или sha, соответсвенно 32 и 40 байт... существует мизерная вероятность, что у двух разных строк хэши совпадут, желательно для отсутствия багов ее разрумить. удачи

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

Код:

string sha1 ( string str [, bool raw_output] )

keenza писал:

можно немного подробнее выделенный абзац? в каком случае хэш совпадет? при использовании: Код: string sha1 ( string str [, bool raw_output] )

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

ШЕФФ писал:

Код: string long2ip ( int proper_address ) int ip2long ( string ip_address ) честно говоря, несколько книг по ПХП прочитал, но такой функции не видел, спасибо.

ты видать Мурзилку читал...

Simplex писал:

что-то вы мелко смотрите... ничего не вижу плохого в таком решении - если скрипт обрабатывает терабайты данных за сутки.

ага мильоны терабайтоф , ты видать не видел с какой переодичностью такие базы умирают вместе с проэктами и серверами

xreload писал:

ага мильоны терабайтоф , ты видать не видел с какой переодичностью такие базы умирают вместе с проэктами и серверами

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

миллион строк в таблице мускуля с неуник. индексом по varchar(32), вставка 50 строк на яве занимает 40мс, проверка наличия 50 строк по описанному индексу занимает примерно столько же. одновременно вышеописанные операции выполняются в среднем 15 потоками, 50 - это среднее значение вставки\селекта за раз.
никогда такие маленькие базы не вешались... может мы друг друга не так поняли?

Дык яж некого не учу и не спорю, что право на жизнь такие минимализмы как сохранения логов сервера в мускуль или запихивание всего интернета в базу еще и с BLOB полями с пикчами , но это правильным назвать нельзя , это элементарное непонимание вопроса и возможных последствий.
Кстати мы тут говорим о связке пхп+мускуль , а не о яве , это тоже давольно важный момент


пы.сы.
15 потоков это не серьезно...