К слову говоря подобная структура на MUMPS будет работать быстрее, чем на SQL. Смотря что, конечно считать транзакцией. Они могут очень отличаться по сложности. Я когда делал тесты с GT.M (бесплатный MUMPS) достигал результатов в 660 000 insert-ов в секунду (база данных на диске, а не в памяти) на 4х3.6GHz Phenom, 8gb, RAID5. Вставлял для теста 10 миллионов записей.
А такой способ хранения очень не оптимален, если приходится производить поиск по полям, какие-то хитрые делать связи между таблицами.
Вычислять аггрегатные функции.
Да и XML не самый быстрый способ сериализации структур.
В данном случае речь идёт о записи в БД. Поскольку в первом случае нужно сформировать один индексный элемент, а во втором два, то первый будет работать быстрее.
С точки зрения того, что структуру можно легко менять второй способ предпочтительней, так как в первом мы будем использовать при считывании:
$piece(record,"~",1)
$piece(record,"~",2)
А это приведёт к тому, что при изменении структуры (например мы добавим возраст перед именем или удалим имя) все цифры «поплывут» и MUMPS-программа станет неработоспособна.
Если нет конфликтов, наездов и превозношений в статье и комментариях автора, то, как правило, всё идёт в плюс.
Если есть наезд на какую-то технологию или класс людей, то будут минуса. Я замечаю как многие авторы пытаются понравиться аудитории, заискивающе спрашивают что-то у неё, специально используют мягкие формулировки, хотя в нормальной жизни так не говорят. Есть сходство с политикой, в части когда нужно понравиться избирателям.
На месте админов хабра я бы учитывал дискуссионность статей и авторов в рейтинге и карме: статья которая вызвала 50 плюсов и 40 минусов ценнее статьи с 10-ю плюсами: она касается большего числа людей, вызывает большее количество комментариев (контента), создаёт эффект мозгового штурма.
О минусах. Какой-нибудь провидец может выдвинуть революционную идею, а массы тупо заминусуют его, т.к. они думают по другому.
Хотя с рекламной точки зрения ресурс должен представлять ценность именно для IT-масс, а иначе рекламодатели будут НАМНОГО меньше заказывать рекламы…
Я проводил такой опрос 6 лет назад. В области основного костяка мало что изменилось — это 18 — 25 лет. А вот людей за 30 немного прибавилось процентов на 5.
Жаль что вы не использовали мою сетку возрастов — тогда можно было точнее определить различия.
Оно совсем не тупое. Если бы важные люди из Intersystem меня послушали и прикрутили бы поддержку PHP, то это было бы фантастически круто.
Иметь многомерное хранилище, выглядящее почти как php-массивы, и работающее почти как оперативная память, но при этом прозрачно всё сохраняющее на винт — это сказка!
А вот DMA тут не причём. Да оно уменьшает загрузку процессора, но в моих расчётах процессор вообще не фигурировал, а только контроллер памяти, который обслуживает и процессор и устройства с DMA.
Есть у меня смутное подозрение, что сама природа DRAM, когда происходят постоянные обновления, даёт примерно такую же нагрузку, что и долбёжка в какую-то определённую ячейку…
Такие сервера, которые 10-20 гигабит раздают, ещё хорошо поискать надо. У гугловских серверов-картриджей (у тех что на картинке) на более 1Гбита сетевуха.
А 1000 — ну это же в среднем. А есть области, которые вообще почти не меняются: коды программ, кешированные данные.
В принципе даже легко ПРИБЛИЗИТЕЛЬНО прикинуть: если 800 МГц шина памяти, 2-х канальный контроллер памяти, допустим каждый канал способен 16 байт передать за рабочий цикл, а всего памяти стоит 8ГБ. Это означает что за 1 секунду в RAM можно записать 25Гб. Что в среднем означает в каждую ячейку всего чуть более 3-х записей/чтений в секунду происходит. И это при максимальной загрузке памяти.
Реальное среднее значение операций чтения/записи на одну ячейку памяти скорее всего будет близко к 1 разу за секунду.
Вроде в таких цифрах для оперативной памяти (в отличие от HDD) нет ничего удивительного — 22 года работал Пионер 11 и 29 лет Пионер 10.
Тем более что
Парадоксальным образом статистика демонстрирует увеличивающиеся темпы роста correctable errors с увеличением возраста модулей, но снижающийся темп для Uncorrectable errors, однако скорее всего это просто результат плановой замены памяти в серверах, которые были замечены за сбоями.
Т.е. если использовать память высочайшего качества, то отсутствие движущихся частей всё-таки даёт о себе знать.
Понятно, что нижеследующие расчёты не претендуют на точность. Я только попытался осмыслить цифры из статьи и сделать выводы.
Итак, в среднем получается 50 ошибок на миллион часов работы сервера или одна ошибка за 2 года и 4 месяца.
Если допустить что в среднюю ячейку производится считывание или запись 1000 раз в секунду, то получим вероятность ошибки 1,4 * 10-11, что на 3-4 порядков больше, чем вероятность ошибки для HDD.
Что странно выглядит и действительно ломает мои представления о сравнительной надёжности памяти и HDD. Хотя с другой стороны, если винт стал ошибаться, то ему дорога на кладбище, а после зависания можно перегрузиться и ещё 2,5 года работать…
Однако если учесть, что 20% модулей дают 90% ошибок, то если повезёт с модулями памяти (вероятность везения 0.8*n, где n число модулей), мы получим вероятность ошибки в 10 раз меньшую.
То есть 1 ошибка на 23 года. Что очень круто.
В практическом смысле получается, что даже из-за одной такой ошибки есть смысл менять модули памяти для ответственных серверов, так как с вероятностью 0,9 мы имеем глючный модуль с повышенной вероятностью ошибок. Если, конечно, BIOS позволяет точно детектировать какой модуль дал ошибку.
Второй практический вывод: вероятность того, что у сервера не будет проблем с памятью зависит от числа её модулей. Есть смысл ставить минимальное число модулей максимальной ёмкости. С оговоркой, что иногда потенциал контроллера памяти раскрывается при чётном или троичном числе модулей.
При этом в абсолютных числах был всегда рост. Насчёт светлых голов: предыдущий пост в блоге оперы написал сотрудник, который в том же посте анонсировал своё увольнение.
Видимо многие головы уйдут не вынеся выкидывание на свалку истории их многолетнего труда.
Было бы на месте Оперы логичным продаться кому-нибудь с деньгами и хорошими рекламными возможностями, но почему-то этого не было сделано.
300 миллионов пользователей — это же почти треть фейсбука!
А такой способ хранения очень не оптимален, если приходится производить поиск по полям, какие-то хитрые делать связи между таблицами.
Вычислять аггрегатные функции.
Да и XML не самый быстрый способ сериализации структур.
Безусловно, в реальной серьёзной системе будут использоваться блокировки по конкретным заказам с вложенными транзакциями.
С точки зрения того, что структуру можно легко менять второй способ предпочтительней, так как в первом мы будем использовать при считывании:
$piece(record,"~",1)
$piece(record,"~",2)
А это приведёт к тому, что при изменении структуры (например мы добавим возраст перед именем или удалим имя) все цифры «поплывут» и MUMPS-программа станет неработоспособна.
Если есть наезд на какую-то технологию или класс людей, то будут минуса. Я замечаю как многие авторы пытаются понравиться аудитории, заискивающе спрашивают что-то у неё, специально используют мягкие формулировки, хотя в нормальной жизни так не говорят. Есть сходство с политикой, в части когда нужно понравиться избирателям.
На месте админов хабра я бы учитывал дискуссионность статей и авторов в рейтинге и карме: статья которая вызвала 50 плюсов и 40 минусов ценнее статьи с 10-ю плюсами: она касается большего числа людей, вызывает большее количество комментариев (контента), создаёт эффект мозгового штурма.
О минусах. Какой-нибудь провидец может выдвинуть революционную идею, а массы тупо заминусуют его, т.к. они думают по другому.
Хотя с рекламной точки зрения ресурс должен представлять ценность именно для IT-масс, а иначе рекламодатели будут НАМНОГО меньше заказывать рекламы…
Жаль что вы не использовали мою сетку возрастов — тогда можно было точнее определить различия.
Опрос о возрасте от 2007 года
А как называется это специальное свойство?
Иметь многомерное хранилище, выглядящее почти как php-массивы, и работающее почти как оперативная память, но при этом прозрачно всё сохраняющее на винт — это сказка!
Есть и другие open source, но не такие серьёзные
С глобалами есть бесплатный качественный продукт с закрытым исходным кодом globalsdb.org/
Есть у меня смутное подозрение, что сама природа DRAM, когда происходят постоянные обновления, даёт примерно такую же нагрузку, что и долбёжка в какую-то определённую ячейку…
А 1000 — ну это же в среднем. А есть области, которые вообще почти не меняются: коды программ, кешированные данные.
В принципе даже легко ПРИБЛИЗИТЕЛЬНО прикинуть: если 800 МГц шина памяти, 2-х канальный контроллер памяти, допустим каждый канал способен 16 байт передать за рабочий цикл, а всего памяти стоит 8ГБ. Это означает что за 1 секунду в RAM можно записать 25Гб. Что в среднем означает в каждую ячейку всего чуть более 3-х записей/чтений в секунду происходит. И это при максимальной загрузке памяти.
Реальное среднее значение операций чтения/записи на одну ячейку памяти скорее всего будет близко к 1 разу за секунду.
Тем более что
Т.е. если использовать память высочайшего качества, то отсутствие движущихся частей всё-таки даёт о себе знать.
Итак, в среднем получается 50 ошибок на миллион часов работы сервера или одна ошибка за 2 года и 4 месяца.
Если допустить что в среднюю ячейку производится считывание или запись 1000 раз в секунду, то получим вероятность ошибки 1,4 * 10-11, что на 3-4 порядков больше, чем вероятность ошибки для HDD.
Что странно выглядит и действительно ломает мои представления о сравнительной надёжности памяти и HDD. Хотя с другой стороны, если винт стал ошибаться, то ему дорога на кладбище, а после зависания можно перегрузиться и ещё 2,5 года работать…
Однако если учесть, что 20% модулей дают 90% ошибок, то если повезёт с модулями памяти (вероятность везения 0.8*n, где n число модулей), мы получим вероятность ошибки в 10 раз меньшую.
То есть 1 ошибка на 23 года. Что очень круто.
В практическом смысле получается, что даже из-за одной такой ошибки есть смысл менять модули памяти для ответственных серверов, так как с вероятностью 0,9 мы имеем глючный модуль с повышенной вероятностью ошибок. Если, конечно, BIOS позволяет точно детектировать какой модуль дал ошибку.
Второй практический вывод: вероятность того, что у сервера не будет проблем с памятью зависит от числа её модулей. Есть смысл ставить минимальное число модулей максимальной ёмкости. С оговоркой, что иногда потенциал контроллера памяти раскрывается при чётном или троичном числе модулей.
Видимо многие головы уйдут не вынеся выкидывание на свалку истории их многолетнего труда.
Было бы на месте Оперы логичным продаться кому-нибудь с деньгами и хорошими рекламными возможностями, но почему-то этого не было сделано.
300 миллионов пользователей — это же почти треть фейсбука!