Прочел интересную статью под названием "Использование MySQL как NoSQL — История о том, как достичь 750,000 запросов в секунду".
Насколько я понял, основной принцип увеличения быстродействия, это обращение к движку InnoDB, напрямую, в обход SQL-слоя. Автор способа (Yoshinori Matsunobu) рекомендует для частых запросов использовать именно такой способ, поскольку при его использовании экономится время, на разбор SQL-запроса, открытие/закрытие таблиц и т.д. При этом для больших и сложный запросов, которые выполняются редко, остается по-прежнему доступным обращение через обычный SQL.
пятница, 29 октября 2010 г.
среда, 27 октября 2010 г.
Где в сети хранить бэкапы
Недавно товарищ посоветовал мне интересный сервис: "Dropbox". Зарегистрировавшись, вы получаете бесплатных 2Gb свободного места и утилиту для синхронизации локальной папки с данными в сети. Причем к вашему аккаунту может быть подключено несколько компьютеров и меняя файлы на одном, утилита синхронизации сначала отправит их на сервер, а откуда они утилитой другого компьютера будут перетянуты на него.
Так вы можете не заморачиваясь использовать одни и те же файлы на работе и дома, например.
Из плюсов можно отметить бесплатность (вообще, там есть и платные тарифные планы, где места больше), простоту установки и использования, стабильность работы. Хочется отдельно сказать о простоте использования - установил и все работает. Не надо ничего нажимать или настраивать.
Так же приятно, что продуман механизм разрешения коллизий. Если файл менялся в двух местах, то при синхронизации будут сохранены обе версии их которых вы сможете выбрать нужную (так же как, например в svn).
Есть и некоторые недостатки. Если меняется большой файл, то он будет отправлен на сервер целиком, а не только та часть, которая поменялась. На медленных каналах это может быть проблемой. В этом смысле разработчикам хорошо было бы поучиться у того же svn или rsync Папка, которая синхронизируется с сетью может быть всего одна. Конечно, было бы лучше, если бы в утилите можно было указать список папок для синхронизации. А так все важное сначала приходится руками собирать в одном месте. Каких-то еще недостатков я не заметил.
Лично у себя я настроил бэкапы следующим образом. На одной машине у меня есть двухгектарный TrueCrypt-овский диск, который я раз в сутки размонтирую, бью на куски по два метра и закидываю в папку dropbox-а. Таким образом я решаю проблему синхронизации больших файлов, каждый раз синхронизируются только те куски, которые поменялись, а это далеко не все 2Gb.
Для контроля на другой, совершенно посторонней машине, я так же поставил синхронизацию с моим dropbox и раз в сутки пытаюсь собрать из двухметровых кусков один двухгиговый файл. Если сборка проходит удачно (проерка по хэшу), я отправляю себе на мыло отчет и делаю копию удачно собранного файла. Если неудачно только отчет. Получается достаточно надежно.
Вообщем, если вам нужно место в сети, где вы могли бы хранить свои данные, добро пожаловать в dropbox: http://www.dropbox.com/
P.S.: Там же есть реферальная программа и если регистрироваться по приглашению, то оба участника получают дополнительных 250Мб. Так, что если хотите, регистрируйтесь по моей ссылке: http://www.dropbox.com/referrals/NTEyNzQ5MDg0OQ
Так вы можете не заморачиваясь использовать одни и те же файлы на работе и дома, например.
Из плюсов можно отметить бесплатность (вообще, там есть и платные тарифные планы, где места больше), простоту установки и использования, стабильность работы. Хочется отдельно сказать о простоте использования - установил и все работает. Не надо ничего нажимать или настраивать.
Так же приятно, что продуман механизм разрешения коллизий. Если файл менялся в двух местах, то при синхронизации будут сохранены обе версии их которых вы сможете выбрать нужную (так же как, например в svn).
Есть и некоторые недостатки. Если меняется большой файл, то он будет отправлен на сервер целиком, а не только та часть, которая поменялась. На медленных каналах это может быть проблемой. В этом смысле разработчикам хорошо было бы поучиться у того же svn или rsync Папка, которая синхронизируется с сетью может быть всего одна. Конечно, было бы лучше, если бы в утилите можно было указать список папок для синхронизации. А так все важное сначала приходится руками собирать в одном месте. Каких-то еще недостатков я не заметил.
Лично у себя я настроил бэкапы следующим образом. На одной машине у меня есть двухгектарный TrueCrypt-овский диск, который я раз в сутки размонтирую, бью на куски по два метра и закидываю в папку dropbox-а. Таким образом я решаю проблему синхронизации больших файлов, каждый раз синхронизируются только те куски, которые поменялись, а это далеко не все 2Gb.
Для контроля на другой, совершенно посторонней машине, я так же поставил синхронизацию с моим dropbox и раз в сутки пытаюсь собрать из двухметровых кусков один двухгиговый файл. Если сборка проходит удачно (проерка по хэшу), я отправляю себе на мыло отчет и делаю копию удачно собранного файла. Если неудачно только отчет. Получается достаточно надежно.
Вообщем, если вам нужно место в сети, где вы могли бы хранить свои данные, добро пожаловать в dropbox: http://www.dropbox.com/
P.S.: Там же есть реферальная программа и если регистрироваться по приглашению, то оба участника получают дополнительных 250Мб. Так, что если хотите, регистрируйтесь по моей ссылке: http://www.dropbox.com/referrals/NTEyNzQ5MDg0OQ
вторник, 26 октября 2010 г.
Рейтинг компаний
Администрация сообщества developers.org.ua, наконец-то опубликовала итоги рейтинга компаний 2010.
В целом результаты интересные. Из "монстров" девелопмента хорошая позиция у Luxoft, что и не удивительно с их учебными центрами и учебными программами. Кадры решают все, а если у тебя еще и "кузница", то не удивительно, что ты впереди.
Среди небольших компаний подозрительно часто упоминается Initto.
GlobalLogic занимает достаточно скромные позиции, зато в нескольких городах. Ну, мы знаем о многих эффектах глобализации и стандартизации, в том числе и о неприятных.
Кто победил, говорить не буду - пойдите и посмотрите сами.
В целом результаты интересные. Из "монстров" девелопмента хорошая позиция у Luxoft, что и не удивительно с их учебными центрами и учебными программами. Кадры решают все, а если у тебя еще и "кузница", то не удивительно, что ты впереди.
Среди небольших компаний подозрительно часто упоминается Initto.
GlobalLogic занимает достаточно скромные позиции, зато в нескольких городах. Ну, мы знаем о многих эффектах глобализации и стандартизации, в том числе и о неприятных.
Кто победил, говорить не буду - пойдите и посмотрите сами.
понедельник, 18 октября 2010 г.
Условия и запросы
При составлении запросов часто бывает так, что нужно вставить условие отбора в запрос в зависимости от того, пустое значение отбора или оно заполнено.
Например, нужно получить список всех товаров по складу, но если в качестве склада передано пустое значение, то необходимо получить список товаров по всем складам (т.е. склад не выбран).
Как правило в таких случаях модифицируют текст запроса "на лету" примерно таким образом:
Без сомнений, такой способ имеет достоинства, но у него есть и существенный недостаток. При таком "ручном" вмешательстве в текст запроса, перестает работать очень удобный инструмент - конструктор запросов. Он просто не понимает наших "посторонних" включений. Особенно ярко это проявляется когда речь идет о "моструозных" запросах на несколько страниц. Сталкиваясь с таким великаном и обнаруживая в нем включения кода 1С, я всегда думаю такие плохие вещи, что будет неловко их тут повторять.
Однако, единственный ли это способ достичь желаемого, сделать так, чтобы склад не учитывался в отборе, если он не заполнен? Не единственный! Если немного пораскинуть мозгами очень просто перенести условную конструкцию внутрь самого запроса, например вот так:
Никакого волшебства, всего-лишь банальное использование оператора "ИЛИ". Если склад не заполнен то и все выражение всегда будет истинным, а значит в выборку попадут все склады.
Конечно, такой способ несколько усложняет само условие запроса, но мне кажется, что это стоит того, чтобы получить преимущества предоставляемые конструктором.
Что же с производительностью? Действительно, производительность в таком случае немного падает. Я сделал небольшую конфигурацию, чтобы сделать замеры. Желающие могут скачать ее и попробовать померить производительность самостоятельно (1C 8.2.10.77).
Исходные данные: 20 документов, 7 товаров, 3 склада, ~10000 вызовов запроса (5000 с пустым и 5000 с заполненным складом).
Запрос в котором условие подставляется в текст средствами языка 1С:
Как видите, 10002 запроса (строка 15) выполняется за 8,2 секунды.
А вот, результаты выполнения запроса с внесенным внутрь условием:
Результат (59-я строка) выполнения - 11,4 секунды.
То-есть 3,2 секунды на ~10000 запросов. Можно было бы провести замеры с вложенными запросами и соединениями или с другими объемами данных, но в целом понятно что для простых случаев потеря производительности несущественная. К тому же запросы-монстры не часто вызываются по 10000 раз за один раз.
Какой из способов использовать, конечно, решать вам.
А я хочу пожелать вам хорошего дня и хорошего кода.
Спасибо за внимание.
P.S.: Статья получила множество отзывов и уважаемое сообщество насоветовало еще кучу способов борьбы с условиями.
Уважаемый alexk-is советует использовать построитель отчета:
4ish использует выбор:
А Vit aka proger изящно применяет "в иерархии":
Ну, и, конечно обсуждение еще продолжается.
Публикация на Инфостарт
Например, нужно получить список всех товаров по складу, но если в качестве склада передано пустое значение, то необходимо получить список товаров по всем складам (т.е. склад не выбран).
Как правило в таких случаях модифицируют текст запроса "на лету" примерно таким образом:
Запрос.Текст =
"ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|" + ?(ЗначениеЗаполнено(Склад),"ГДЕ Учет.Склад.Ссылка = &Склад","");
Без сомнений, такой способ имеет достоинства, но у него есть и существенный недостаток. При таком "ручном" вмешательстве в текст запроса, перестает работать очень удобный инструмент - конструктор запросов. Он просто не понимает наших "посторонних" включений. Особенно ярко это проявляется когда речь идет о "моструозных" запросах на несколько страниц. Сталкиваясь с таким великаном и обнаруживая в нем включения кода 1С, я всегда думаю такие плохие вещи, что будет неловко их тут повторять.
Однако, единственный ли это способ достичь желаемого, сделать так, чтобы склад не учитывался в отборе, если он не заполнен? Не единственный! Если немного пораскинуть мозгами очень просто перенести условную конструкцию внутрь самого запроса, например вот так:
Запрос.Текст =
"ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|ГДЕ
| (&Склад = ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка)
| ИЛИ Учет.Склад.Ссылка = &Склад)";
Никакого волшебства, всего-лишь банальное использование оператора "ИЛИ". Если склад не заполнен то и все выражение всегда будет истинным, а значит в выборку попадут все склады.
Конечно, такой способ несколько усложняет само условие запроса, но мне кажется, что это стоит того, чтобы получить преимущества предоставляемые конструктором.
Что же с производительностью? Действительно, производительность в таком случае немного падает. Я сделал небольшую конфигурацию, чтобы сделать замеры. Желающие могут скачать ее и попробовать померить производительность самостоятельно (1C 8.2.10.77).
Исходные данные: 20 документов, 7 товаров, 3 склада, ~10000 вызовов запроса (5000 с пустым и 5000 с заполненным складом).
Запрос в котором условие подставляется в текст средствами языка 1С:
Как видите, 10002 запроса (строка 15) выполняется за 8,2 секунды.
А вот, результаты выполнения запроса с внесенным внутрь условием:
Результат (59-я строка) выполнения - 11,4 секунды.
То-есть 3,2 секунды на ~10000 запросов. Можно было бы провести замеры с вложенными запросами и соединениями или с другими объемами данных, но в целом понятно что для простых случаев потеря производительности несущественная. К тому же запросы-монстры не часто вызываются по 10000 раз за один раз.
Какой из способов использовать, конечно, решать вам.
А я хочу пожелать вам хорошего дня и хорошего кода.
Спасибо за внимание.
P.S.: Статья получила множество отзывов и уважаемое сообщество насоветовало еще кучу способов борьбы с условиями.
Уважаемый alexk-is советует использовать построитель отчета:
Yashazz ставит комментарии, выполняет поиск и замену в тексте запроса перед выполнением, но сокрушается, что конструктор режет комментарии:ПостроительОтчета.Текст ="ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|{ГДЕ
| Учет.Склад.*}";ПостроительОтчета.ПолучитьЗапрос().Выполнить();
Зато Alias прекрасно развивает идею и советует делать так:ТекстЗапроса =
"ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|ГДЕ
|Склад = &УсловныйСклад
|//УсловиеНаТовар//";
...
СтрЗаменить(ТекстЗапроса,"//УсловиеНаТовар//","И Товар = &УсловныйТовар");
Без сомнения в способе куча плюсов - и конструктор не режет ничего и запрос читается нормально и тормозов нет.Запрос.Текст =
"ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|ГДЕ
| &УсловиеСклада";
Запрос.Текст = СтрЗаменить(Запрос.Текст, "&УсловиеСклада",?(ЗначениеЗаполнено(ВыбСклад),"Учет.Склад.Ссылка = &Склад","Истина"));
4ish использует выбор:
Тоже хороший способ.Запрос.Текст =
"ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|ГДЕ
|ВЫБОР
| КОГДА &Склад <> ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка)
| ТОГДА ПоступлениеТоваровУслугТовары.Ссылка.Склад = &Склад
| ИНАЧЕ ИСТИНА
|КОНЕЦ";
А Vit aka proger изящно применяет "в иерархии":
Всем спасибо за замечательные подсказки, я обязательно возьму кое-что себе на вооружение.Запрос.Текст =
"ВЫБРАТЬ
| Учет.Товар,
| Учет.Количество
|ИЗ
| Документ.Учет КАК Учет
|ГДЕ
| Учет.Склад в иерархии( &Склад))";
Ну, и, конечно обсуждение еще продолжается.
Публикация на Инфостарт
воскресенье, 17 октября 2010 г.
Резонанс
Недавно пришло письмо от одного из участников developers.org.ua смысл которого сводился к тому, что некий аноним оставил негативный отзыв об одной девелоперской компании, который администрация сайта удалила по просьбе упоминаемой компании.
Не буду вдаваться в подробности и не возьмусь судить такая ли это плохая компания или просто какой-то неумеха-неудачник решил нагадить "обидчикам" в тапки - все равно со стороны этого не понять. Но хочу обратить внимание на то, что факт удаления сообщения все-таки был (если это не совсем уж "резиновая утка"). Что весьма странно, учитывая, что developers сейчас проводит платный рейтинг компаний.
Мне кажется, что это событие должно подорвать доверие к developers, как к "независимому арбитру".
Пока непонятно чем это может закончится, но на мой взгляд было бы лучше всего, если бы developers опубликовали текст договора, который упоминается в анонсе рейтинга, чтобы все желающие могли убедиться, что там хотя бы нет пункта "компания может не платить, если рейтинг ей не понравился" (с просьбой о публикации текста я только-что отправил им письмо).
А анониму, начавшему этот "бокс по-интернету" было бы хорошо развиртуализироваться и опубликовать свое резюме. Тогда, по крайней мере все, могли бы прочесть, что у борца за правду нет опыта работы и он "только что выучил бейсик" но полон амбиций или, например, что это "зубр" девелопмента имеющий опыт работы во множестве крупных компаний. Согласитесь, это многое бы решило в этом споре.
Конечно, все это лишь мои личные рассуждения, но мне кажется, что открытость в данном случае (да, как и во многих других) это единственный путь выйти с достоинством из этой неприятной ситуации.
P.S.: По результатам переписки с develpoers понятно, что администрация в принципе готова отвечать на вопросы и разъяснять неразъясненное. Могу посоветовать всем заинтересованным лицам писать письма, приезжать в офисы, звонить и задавать вопросы. И на вопросы будут ответы.
Не буду вдаваться в подробности и не возьмусь судить такая ли это плохая компания или просто какой-то неумеха-неудачник решил нагадить "обидчикам" в тапки - все равно со стороны этого не понять. Но хочу обратить внимание на то, что факт удаления сообщения все-таки был (если это не совсем уж "резиновая утка"). Что весьма странно, учитывая, что developers сейчас проводит платный рейтинг компаний.
Мне кажется, что это событие должно подорвать доверие к developers, как к "независимому арбитру".
Пока непонятно чем это может закончится, но на мой взгляд было бы лучше всего, если бы developers опубликовали текст договора, который упоминается в анонсе рейтинга, чтобы все желающие могли убедиться, что там хотя бы нет пункта "компания может не платить, если рейтинг ей не понравился" (с просьбой о публикации текста я только-что отправил им письмо).
А анониму, начавшему этот "бокс по-интернету" было бы хорошо развиртуализироваться и опубликовать свое резюме. Тогда, по крайней мере все, могли бы прочесть, что у борца за правду нет опыта работы и он "только что выучил бейсик" но полон амбиций или, например, что это "зубр" девелопмента имеющий опыт работы во множестве крупных компаний. Согласитесь, это многое бы решило в этом споре.
Конечно, все это лишь мои личные рассуждения, но мне кажется, что открытость в данном случае (да, как и во многих других) это единственный путь выйти с достоинством из этой неприятной ситуации.
P.S.: По результатам переписки с develpoers понятно, что администрация в принципе готова отвечать на вопросы и разъяснять неразъясненное. Могу посоветовать всем заинтересованным лицам писать письма, приезжать в офисы, звонить и задавать вопросы. И на вопросы будут ответы.
четверг, 7 октября 2010 г.
Суперпозиция котов.
Шрёдингер ходил по комнате в поисках нагадившего котёнка, а тот сидел в коробке ни жив ни мертв.
понедельник, 4 октября 2010 г.
Cочинение 7-летнего Тараса
Кем я хочу стать когда буду большим
Я хочу стать программистом, когда выросту большим, потому что это классная работа и простая. Поэтому в наше время столько программистов и все время становится больше.
Программистам не нужно ходить в школу, им нужно учиться читать на компьютерном языке, что бы они могли с компьютером разговаривать.
Думаю, что они должны уметь читать тоже, что бы знать в чем дело, когда все напереполох.
Программисты должны быть смелыми, что бы не пугаться, когда все перепуталось так что никто не разберет, или если придется разговаривать на английском языке по-иностранному, что бы знать, что надо делать.
У программистов должно быть хорошее зрение, что бы видеть сквозь одежду и что бы не бояться секретарш, потому что с ними приходиться работать.
Еще мне нравитса зарплата, которую программисты получают.
Они получают столько денег, что не успевают их все тратить.
Это происходит потому, что все считают работу программиста трудной, кроме программистов, которые знают, как это просто.
Нет ничего такого, что бы мне не понравилось, кроме того что девочкам нравятся программисты и все хотят выйти за них замуж, и поэтому женщин надо гнать, что бы не мешали работать.
Надеюсь, что у меня нет аллергии на офисную пыль, потому что на нашу собаку у меня аллергия.
Eсли у меня будет аллергия на офисную пыль, программиста из меня не получится и придется искать настоящую работу.
Оригинал тут.
P.S.: Все так и есть, все так и есть!!!
Я хочу стать программистом, когда выросту большим, потому что это классная работа и простая. Поэтому в наше время столько программистов и все время становится больше.
Программистам не нужно ходить в школу, им нужно учиться читать на компьютерном языке, что бы они могли с компьютером разговаривать.
Думаю, что они должны уметь читать тоже, что бы знать в чем дело, когда все напереполох.
Программисты должны быть смелыми, что бы не пугаться, когда все перепуталось так что никто не разберет, или если придется разговаривать на английском языке по-иностранному, что бы знать, что надо делать.
У программистов должно быть хорошее зрение, что бы видеть сквозь одежду и что бы не бояться секретарш, потому что с ними приходиться работать.
Еще мне нравитса зарплата, которую программисты получают.
Они получают столько денег, что не успевают их все тратить.
Это происходит потому, что все считают работу программиста трудной, кроме программистов, которые знают, как это просто.
Нет ничего такого, что бы мне не понравилось, кроме того что девочкам нравятся программисты и все хотят выйти за них замуж, и поэтому женщин надо гнать, что бы не мешали работать.
Надеюсь, что у меня нет аллергии на офисную пыль, потому что на нашу собаку у меня аллергия.
Eсли у меня будет аллергия на офисную пыль, программиста из меня не получится и придется искать настоящую работу.
Оригинал тут.
P.S.: Все так и есть, все так и есть!!!
Авто-фокус
Об интересной системе управления собственным списком задач пишет Алексей Рубцов.
Встречайте - Авто-фокус.
Встречайте - Авто-фокус.
Подписаться на:
Сообщения (Atom)