Content-aware Image Resize (не Fill!) (http://www.youtube.com/watch?v=c-SSu3tJ3ns) как раз и появился в 2007 году, затем эту команду нанял Adobe. После презентации и появилась масса кодов на самых разных языках, которые реализовывали эту функциональность.
Шоу «Penn&Teller's Bullshit!» целую серию посвятила «взрослым» полиграфам… что интересно — обмануть их можно именно тем способом, который Вы случайно обозначили в конце статьи: «поджать ягодицы», точнее говоря «сжимать» и «расслаблять», если не ошибаюсь — расслаблять когда врешь и сжимать когда говоришь правду и полиграф запутывается.
Проще говоря, допустим есть три записи:
1. ИНТЕРЕС
2. ТЕХНИЧЕСКИЙ ПРОГРЕСС
3. РЕСУРСЫ
соответственно у Вас индекс:
ИНТ = 1
НТЕ = 1
…
РЕС = 1,2,3
ЕСУ = 3
|РЕ = 3 < — РЕ, стоящее в начале слова
…
делается запрос допустим «РЕСУ», запрос к индексу дает:
|ре = 3
рес = 1,2,3
есу = 3
(3)&(1,2,3)&(3) = (3)
следовательно это слово (частично) есть только в третьей строке.
Ну «своих» — я так понимаю, не «сделанных в DHL», а «купленных». Я не говорю, что Гуглу не надо покупать каналы — но почему он должен становиться провайдером для конечный пользователей исходя из того, что они имеют сколько-то процентов траффика — не понимаю.
Другой вопрос — если бы опубликовали реальные факты, что гугл может сделать лучше маршрутизаторы, лучше цены и т.п. — пожалуйста, пусть становятся.
Мне мотивация в статье не понятна (проценты траффика -> провайдер).
Логика что-то не очень понятна — у Гугла много посетителей и поэтому «другого пути у Google нет» как стать провайдером?
Тогда у нас наверное Яндекс и ВКонтакте должны становиться провайдерами?..
А UPS с DHLем, как крупнейший грузоперевозчик — должен начать строить самолеты и прокладывать дороги?..
Заодно давайте МакДональдс, который занимает наш желудок 4% времени — пусть будут главными врачами по желудкам.
млин… я не знаю как подробнее объяснить уже.
fallen тестировал на линухе с innodb_plugin (отдельно от топика! в этой ветке!), у него получились результаты с ошибкой (обе таблицы innodb, про которое он и сказал, что одна таблица создалась по дефолту (Как иннодб), а вторая с четким указанием, (тоже иннодб!)), ошибку он исправил. у него настройки по умолчанию (дефолту) создавать innodb, у меня по дефолту — myisam…
Ну так в результате мы возьмем среднее между двумя тестами (у меня и у Вас) и получается — что примерно равны — на каких-то настройках (оборудовании) будет монго вырываться вперед, на каких-то мускуль — это уже от конкретики зависит. А базовая линия — что примерно одинаковы.
Все, кто предлагает расширить тест, уточнить его и т.п. — мне это не интересно, я узнал что хотел — что все примерно одинаковые — никто никого не убил, никто не тупит. А дальше — все исходники у вас есть — дерзайте.
> Хотел попробовать в одном проекте, но теперь вижу, что ценность оного для меня никакая, так как там упор на чтение.
Вот, блин, все верно — вот аудитория такого теста (и я тоже) — и он нам полезен! (И мне самому тоже — сравнить не очень известную систему и понять — не устарел ли уже mysql).
Да, соглашаюсь, но Вы же не можете утверждать, что тест НЕ верный? Он просто не отвечает Вашим требованиям об опубликованной информации. Но если бы я все это описал — от этого мускуль бы не стал в три раза быстрее?
Опять же — мне лично (как автору этого топика) важно например было узнать, что в среднем монго опережает mysql на запись и значительно. Разница в 10-40% на чтение — для меня не играет роли и не для кого особо не должна (в таких тестах), потому что такие выигрыши можно как раз делать разным использованием технологий (bulk insert, begin-commit, multi_get, отложенные ключи и т.п.).
Просто для чего такой тест может быть полезен — так это, например, увидели бы мы что мускуль проигрывает на таких задачах в 10 раз… то можно было бы сделать вывод, что мускуль — пережиток прошлого. Такого вывода сделать нельзя, можно только, что системы примерно равны по производительности и дальнейшее выжимание мощности из них зависит от самого программера.
Сколько ни тужься программеру — но Python не обгонит C — мы это знаем благодаря таким же «сферическим» тестам и можем делать разумный выбор.
Вот с этим плюсом я согласен — есть очень много проектов, которые нагружены именно на запись! И Монго тут показывает преимущество, даже в сферическом тесте.
www.cs.princeton.edu/gfx/pubs/Barnes_2009_PAR/patchmatch.pdf
www.youtube.com/watch?v=dgKjs8ZjQNg (английский)
Сама серия (на английском):
www.youtube.com/watch?v=u9NSXy176oA (ч.1)
www.youtube.com/watch?v=bScv6kfxRyE (ч.2.)
Проще говоря, допустим есть три записи:
1. ИНТЕРЕС
2. ТЕХНИЧЕСКИЙ ПРОГРЕСС
3. РЕСУРСЫ
соответственно у Вас индекс:
ИНТ = 1
НТЕ = 1
…
РЕС = 1,2,3
ЕСУ = 3
|РЕ = 3 < — РЕ, стоящее в начале слова
…
делается запрос допустим «РЕСУ», запрос к индексу дает:
|ре = 3
рес = 1,2,3
есу = 3
(3)&(1,2,3)&(3) = (3)
следовательно это слово (частично) есть только в третьей строке.
Другой вопрос — если бы опубликовали реальные факты, что гугл может сделать лучше маршрутизаторы, лучше цены и т.п. — пожалуйста, пусть становятся.
Мне мотивация в статье не понятна (проценты траффика -> провайдер).
Тогда у нас наверное Яндекс и ВКонтакте должны становиться провайдерами?..
А UPS с DHLем, как крупнейший грузоперевозчик — должен начать строить самолеты и прокладывать дороги?..
Заодно давайте МакДональдс, который занимает наш желудок 4% времени — пусть будут главными врачами по желудкам.
fallen тестировал на линухе с innodb_plugin (отдельно от топика! в этой ветке!), у него получились результаты с ошибкой (обе таблицы innodb, про которое он и сказал, что одна таблица создалась по дефолту (Как иннодб), а вторая с четким указанием, (тоже иннодб!)), ошибку он исправил. у него настройки по умолчанию (дефолту) создавать innodb, у меня по дефолту — myisam…
при чем здесь изначальные числа из топика?
habrahabr.ru/blogs/mysql/87620/#comment_2625002
10000 items
MyISAM INSERTs 27.0K per sec
INNODB INSERTs 28.6K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 27.9K per sec
на самом деле тут где написано «myisam» был тоже «innodb» (по умолчанию созданный так)…
Вот, блин, все верно — вот аудитория такого теста (и я тоже) — и он нам полезен! (И мне самому тоже — сравнить не очень известную систему и понять — не устарел ли уже mysql).
Опять же — мне лично (как автору этого топика) важно например было узнать, что в среднем монго опережает mysql на запись и значительно. Разница в 10-40% на чтение — для меня не играет роли и не для кого особо не должна (в таких тестах), потому что такие выигрыши можно как раз делать разным использованием технологий (bulk insert, begin-commit, multi_get, отложенные ключи и т.п.).
Просто для чего такой тест может быть полезен — так это, например, увидели бы мы что мускуль проигрывает на таких задачах в 10 раз… то можно было бы сделать вывод, что мускуль — пережиток прошлого. Такого вывода сделать нельзя, можно только, что системы примерно равны по производительности и дальнейшее выжимание мощности из них зависит от самого программера.
Сколько ни тужься программеру — но Python не обгонит C — мы это знаем благодаря таким же «сферическим» тестам и можем делать разумный выбор.