За последние 24 часа нас посетил 53691 программист и 1765 роботов. Сейчас ищут 1463 программиста ...

Разработчики MySQL ступили?

Тема в разделе "Прочее", создана пользователем Dagdamor, 2 сен 2008.

Статус темы:
Закрыта.
  1. DarkElf

    DarkElf Активный пользователь

    С нами с:
    22 окт 2006
    Сообщения:
    1.632
    Симпатии:
    0
    а не проще ли еще один сервер в кластер в этом случае добавить?:)
     
  2. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Dagdamor
    Отмазка: буду писать немного в резком тоне, но это не личное, по моему ИМХО такой ответ уместен, так что не воспринимай близко к сердцу пожалуйста :)

    Вот ты там сидишь, рассуждаешь о кодировках, о UTF-8, о кучи настроек по кодировкам, collocate в MySQL. А ведь дальше WEB сайтов ты просто не смотришь. Отнюдь, MySQL не одними WEB проектами рулит. Есть кучи систем управления предприятиями, самых разных, написанных с использованием MySQL и часто такие системы не ограничиваются чисто одним источником данных. Часто данные приходят от других систем, которые работают в других кодировках, баз там несколько, разных, зачастую в разных кодировках (как исторически, так и с точки зрения гос. стандартов (пример - банковские системы Латвии - они законом обязаны работать в национальной кодировке - windows-1257, а подавляющее большинство сайтов делаются в UTF-8, т.к. у нас как правило делают 3 языка - латышский, русский и английский). В больших системах данные часто гоняются от одного сервера к другому и как правило данные перекодируют силами самого DB сервера - поставили правильные параметры соединения, поставили таблицам и полям кодировки и типы сравнения и всё работает. Пришли в cp1251 или windows-1257 - сохранились реально в utf-8. Забирают данные - установили что хотят в UTF-16 - сервер всё сделал и отдал - забирающий доволен и не думает о кодировках лишний раз. Запомните раз и навсегда - не одним WEB мы живём, и есть системы автоматизированного управления и учёта стоимостью на миллионы долларов, где это всё используется (я с парой таких сейчас имею дело, дабы небыло обвинений что я ничего не понимаю) и где вы со своими принципами построения WEB сайтов сядете в лужу такого размера, что потом будете много лет выкручиваться.

    Система сделана не идиотами и если бы это не нужно было, то не сделали бы такую систему.

    А спорить о индексах глупо, потому что каждая СУБД реализует их по разному и работает с ними по разному.


    О UTF-8 - зря зря вы, большие системы как раз и работают с XML много и тут UTF-8 сейчас по всюду (частный случай: система импортирует расписание перелётов с 4-х разных источников и списки отелей и данных о них из 14-ти источников на разных языках. Вы хотите что бы каждый язык был в своей кодировке? Разработчики тех систем, из которых вы берёте эти данные скажут либо используйте UTF-8, либо валите нафиг - они понимают, что они не единственный источник и устанавливая национальные кодировки они только сделают систему менее конкурентно способной). Пора уже думать не только как программист, но и с экономической точки зрения. Будете это понимать - будете успешным исполнителем, который зарание облегчает себе жизнь и малой кровью за хорошую оплату может добавить важный функционал.
     
  3. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    Зоопарк настроек кодировок в mysql - действительно жуть. Имело смысл исользовать только UTF-8, ну максимум еще добавить кодировку клиента. Кодировка индекса - лишнее. Движек должен сам оптимизировать индекс с учетом используемых символов.
     
  4. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    DarkElf
    Ппц... ты бы еще на пустой строке сравнил. А вот и нормальный тест подоспел.
    Таблица:
    [sql]CREATE TABLE test (
    id INT NOT NULL AUTO_INCREMENT,
    text_cp1251 LONGTEXT CHARACTER SET cp1251 NOT NULL,
    text_utf8 LONGTEXT CHARACTER SET utf8 NOT NULL,
    PRIMARY KEY (id));[/sql]

    Заполняем ее тестовыми данными:
    PHP:
    1. <?php
    2.  
    3. // Тестовая строка длиной в 32 Кб
    4. $text="";
    5. for($index=0; $index<1000; $index++) $text.=implode("",range("А","Я"));
    6. // Заносим в таблицу 1000 таких строк
    7. for($index=0; $index<1000; $index++)
    8.   mysql_query("INSERT INTO test (text_cp1251,text_utf8) VALUES ('$text','$text')");
    Собсно замеры:
    PHP:
    1. <?php
    2.  
    3. // Скорость строковых операций в MySQL при использовании cp1251
    4. $time=array_sum(explode(" ",microtime()));
    5. mysql_query("SELECT AVG(CHAR_LENGTH(text_cp1251)) FROM test"); // 32000.0000
    6. $time=array_sum(explode(" ",microtime()))-$time;
    7. echo "cp1251: ".$time."<br>";
    8.  
    9. // Скорость строковых операций в MySQL при использовании UTF-8
    10. $time=array_sum(explode(" ",microtime()));
    11. mysql_query("SELECT AVG(CHAR_LENGTH(text_utf8)) FROM test"); // 32000.0000
    12. $time=array_sum(explode(" ",microtime()))-$time;
    13. echo "UTF-8: ".$time."<br>";
    Результаты:
    С UTF-8 запрос выполнялся в 5 раз дольше.

    Всем
    Еще раз подчеркиваю, я не против Юникода, а против UTF-8, ибо формат этот, мягко говоря, далек от совершенства. Нужна универсальная кодировка? Юзайте UTF-16 на здоровье. Там каждый символ занимает 2 байта, и проблем со строковыми функциями нет. Надеюсь, нынешняя истерия очень быстро пройдет, и мир перейдет на эту кодировку.
     
  5. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    это проблемы конкретной реализации
     
  6. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Ti
    Ага, разработчики мускула напихали noop-ов в код, идиоты ;)
     
  7. DarkElf

    DarkElf Активный пользователь

    С нами с:
    22 окт 2006
    Сообщения:
    1.632
    Симпатии:
    0
    ты писал?
    я это и тестил.
    разница между парой результатов - на погрешности измерений.

    а по поводу самого теста:
    1) а зачем использовать longtext для данных в 32кб?
    2) а если создать отдельную таблицу в utf и отдельную в cp1251?
    3) а почему используется допотопное расширение mysql вместо более современного mysqli?
    4) а если прогнать не такой достаточно экзотический запрос, а куда более часто встречающиеся, например, where с = и с LIKE?
     
  8. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    DarkElf
    У тебя строка была какой длины? Десять символов?

    1) Пжалста, замени на TEXT или MEDIUMTEXT. Вряд ли что-то изменится.
    2) Опять-таки, сделай сам и проверь. Код я выложил. Ооочень сомневаюсь, что разнесение по разным таблицам поможет.
    3) А в чем в данном конкретном случае разница? Думаешь, запрос, переданный мускулу через mysqli, выполняется другим, волшебным и в 10 раз более быстрым способом?
    4) См. пункт 2.

    UPD: Все, увидел. 300 символов. ЛОЛ. Это немногим лучше, чем 10, ибо один-единственный вызов strlen() или даже mb_strlen() незаметен на фоне запуска песочницы PHP. Совершенно непоказательный тест, ты по сути замерял работу пустого скрипта.
     
  9. DarkElf

    DarkElf Активный пользователь

    С нами с:
    22 окт 2006
    Сообщения:
    1.632
    Симпатии:
    0
    Dagdamor

    строка была под 400 символов длиной.

    вечером результаты непременно выложу.
     
  10. MiksIr

    MiksIr Активный пользователь

    С нами с:
    29 ноя 2006
    Сообщения:
    2.339
    Симпатии:
    44
    Ах, да, iconv вынесенный в отдельный функционал перестает быть iconv и становится нейронной сетью.

    О UTF8 - давайте прекратим споры? Те, кто его использует - его использует. Те, у кого на него фобия, будет охать, ахать, ссылаться на массовую истерию и строить тесты.

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

    У индекса _нет_ кодировки, кодировка есть у исходных данных, на основе которых строится индекс. Но допустим вы называете именно это кодировкой индекса. Первый пост говорит, что если оперировать кодировкой индекса, то можно отказаться от всех других кодировок включая (!) кодировку соединения. Итак, вопрос - как это будет работать. Расскажите на пальцах.
     
  11. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    MiksIr
    Свои считайте. То, что вы любите погадить в теме, я уже видел на предыдущей странице.
    Еще раз: нет внятных аргументов - не лезьте.
     
  12. Anonymous

    Anonymous Guest

    тема закрыта.
     
  13. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Даже ОН! ОН - самый терпеливый из модераторов - не выдержал этого безобразия и необразованности! :)

    З.Ы. Не удержался :p
     
Статус темы:
Закрыта.