Проектирование системы обработки и хранения данных в условиях высокой нагрузки на примере компании ООО «Яндекс»

1. Актуальность и необходимость средств обработки данных в высоко нагруженных проектах

1.1 Обработка данных, способы, решения

яндекс база данный интерфейс

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

Как правило, для хранения данных используются специальные форматы, которые позволяют структурировать информацию и сохранить её на информационном носителе. Такой подход позволяет запрограммировать логику агрегирования данных и построить динамическую систему.

В наше время особое распространение получила так называемая «реляционная» модель хранения данных — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты а) структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений;

б) аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных;

в) аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

Кроме того, в состав реляционной модели данных включают теорию нормализации.

Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

Для лучшего понимания РМД следует отметить три важных обстоятельства а) модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;

б) для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;

в) наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.

Основные свойства реляционных баз данных — это а) каждый элемент таблицы — один элемент данных;

б) все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.);

в) каждый столбец имеет уникальное имя;

г) одинаковые строки в таблице отсутствуют;

д) порядок следования строк и столбцов может быть произвольным.

Рисунок 1 — Пример реляционной базы данных Для возможности динамически запрашивать данные из хранилища был придуман специальный язык запросов SQL (Structured Query Language). Язык SQL представляет собой совокупность а) операторов;

б) инструкций;

в) и вычисляемых функций.

SQL не привязан ни к какой конкретной системе управления данными (СУБД), и поэтому один и тот же запрос с большой вероятностью будет одинаково обработан множеством различных систем.

Преимуществом такого, подходя хранения данных, является его прозрачность и гибкость, даже в случае больших масштабов обработки данных структура СУБД остаётся простой и понятной, однако обработка сложных запросов, как правило, требует значительных вычислительных ресурсов и может выполняться заметное время.

Альтернативой реляционным СУБД являются файло-ориентированные хранилища, например XML. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML). В отличие от реляционных СУБД, которые используют абстракцию таблиц, текстовые форматы можно представить как множество вложенных списков (рисунок 2).

Рисунок 2 — Представление текстового формата HTML в виде дерева

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

Подобно SQL в реляционных СУБД, для множества файловых хранилищ существуют свои языки запросов, например для XML — это XPath.

1.2 Текстовый формат хранения данных JSON

JSON (JavaScript Object Notation) — объектная нотация JavaScript, текстовый формат хранения данных основанный на лексемной представлении объектов в ЯВУ JavaScript. В качестве основной структуры используются понятия массива (рисунок 3) и хеш-таблицы (рисунок 4).

Рисунок 3 — Представление массива в JSON

Рисунок 4 — Представление хеш-таблицы в JSON

Рисунок 5 — Виды данных в JSON

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

Хеш-таблицей называется неупорядоченный набор данных, типа ключ: значение. В отличие от массивов, где ключом по сути является целое неотрицательное число, в хеш-таблицах ключом может быть любой строчное выражение, тем самым давая возможность прямого обращения к ячейки данных. Формат JSON является нативным для языка JavaScript, т. е. он может быть преобразован сразу с помощью вызова интерпретатора JavaScript или вызова специальной команды eval, однако, данный формат является независимым от средств разработки и может использоваться в других языках.

Главным преимуществом JSON является его компактность и возможность «сверхбыстрого» использования в совокупности с JavaScript, т.к. данные могут без дополнительных обработок преобразованы в соответствующую сущность в оперативной памяти и тем самым позволяя работать с данными, как с простым объектом JavaScript, а т.к. доступ к данным в оперативной памяти в десятки сотен раз быстрее чем доступ к файлу на жёстком диске, то мы получаем возможность использования почти мгновенных механизмов обработки данных.

1.3 Кеширование данных в оперативной памяти, техника частичного агрегирование

Кеширование данных — это способ оптимизации работы БД, который не является новым и уже много лет используется везде, где нужна скорость и надёжность. Основной принцип такого подхода заключается в том, что часто-используемые данные не удаляются из памяти компьютера после успешного завершения запроса, а сохраняются для дальнейшего использования, тем самым предотвращая необходимость вторичного поиска данных в хранилище. Использование такого подхода позволяет в сотни раз увеличить производительность серверов баз данных, а поскольку общение с БД, как правило, является самым «дорогим», то и всего приложения в целом. На базе такого подходя реализованы библиотеки MemCache и MemCached, которые успешно используются в таких сверх нагруженных проектах, как Facebook или Википедия.

Ограничивающим фактором использования такого подхода является быстрая конечность оперативной памяти, которая в отличии от жёсткого диска, который может хранить несколько терабайт данных, позволяют хранить лишь несколько десятков гигабайт информации. Проблема решается физическим увеличением памяти за счёт добавления новых компьютеров, а также за счёт системы «временного» кеширования. Т. е. данные закешированные в памяти хранятся не вечно, а лишь в течение некоторого времени и по истечению которого они удаляются и освобождают память.

Недостатком кеширования запросов, является и то, что кешированию подвержены не исходные данные, а некоторый результат запроса, что может привести к эффекту «протухания» данных, когда информация хранимая в кеше не соответствует действительности. Для решения данной проблемы необходимо реализовывать дополнительный интерфейс синхронизации, однако без должного инструментария данная задача может оказаться не из лёгких. Однако, в случае использования совокупности: JSON и JavaScript данная задача может быть легко решена, в виду близости этих двух инструментов.

Ещё один эффективный способ оптимизации обработки данных основывается на частично распределение нагрузки на компьютеры клиентов (компьютеры осуществляющие работу с БД). При таком подходе сервер отдаёт не конечный результат запроса, а некоторое не агрегированное множество, которое затем окончательно обрабатывается средствами пользовательского компьютера, а также все последующие запросы имеют шанс быть найдены в локальной БД и тем самым значительно уменьшить количество запросов к серверу.

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

2. Постановка задачи

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

Компания ООО «Яндекс» является лидером в ИТ индустрии на Российском рынке и в некоторых странах СНГ, а также является 5-й по популярности поисковой системе в мире. Ежедневно компания принимает и обслуживает несколько десятков миллиардов запросов по всему миру и для этого необходима поддержка десятков тысяч обслуживающих серверов.

Проблема поддержки и обслуживания высоко-нагруженных проектов является одна из самых затратных в сфере ИТ бизнеса, следовательно при разработке нового продукта его архитектура должна отвечать следующим факторам:

а) лёгкая масштабируемость;

б) быстрый доступ;

в) минимизация избыточности.

Мне была поставлена задача о пересоздании аналитического отчёта Яндекс. Метрики «Карта путей» с целью оптимизации его логики. Использование старой версии отчёта было затруднительным для владельцев крупных сайтов, т.к. загрузка и обработка отчёта требовала значительного времени (10−15 секунд) и создавала сильную нагрузку серверу.

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

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

В качестве языка разработки был выбран JavaScript, ввиду его всеобщей распространённости и высокой динамичности, позволяющий ему работать на любых устройствах.

Ключевым фактором при разработке, была также скорость «живой» работы на клиенте, конечный продукт должен был быстро работать, как на домашних компьютерах, так и на телефонах и планшетах.

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

Ожидаемым увеличением скорости работы отчёта при использовании новой схемы, после проведения анализов, примерно в 2−3 раза.

3. Инструментальные средства разработки

Интегрированные среды разработки (IDE) — являются важнейшим инструментом в процессе разработки приложений, т.к. помимо текстового редактора в включат в себя целый спектр подпрограмм для решения следующего ряда задач а) подстветка синтаксиса;

б) автодополнения;

в) отладка работы кода;

г) система контроля версий;

д) система контроля проектов;

е) клиенты для удалённого доступа.

Программ реализующих данных функционал довольно много, но я рассмотрю три: Adobe Dreamweaver, Aptana Studio, Microsoft Visual Studio.

Рассмотрим каждую из предложенных IDE.

3.1 Adobe Dreamweaver

Широкопрофильные кроссплатформенный (Windows, Mac) коммерческий WYSIWYG редактор от компании Adobe. На сегодняшний день является одним из самых передовых и качественных сред разработки веб приложения, содержит в себе инструментарии для работы с языками а) XML, HTML;

б) CSS;

в) JavaScript;

г) PHP;

д) Java;

е) ActionScript;

ж) C#;

з) VB.NET;

и) Jscript.NET;

к) VB Script;

л) Cold Fusion.

Рисунок 6 — Окно приветствия Adobe Dreamweaver CS6

Dreamweaver имеет хорошую интеграцию со многие популярными фреймворками, как например jQuery для JavaScript или Adobe Spry. Также в набор инструментов входят средства для отладки под мобильные устройства, а интегрированный браузерный движок WebKit позволяет не выходя из программы видеть конечный результат работы. IDE хорошо интегрирована с остальными продуктами компании Adobe.

Adobe Dreamweaver является платным продуктом и по состоянию на февраль 2012, кроме варианта оплатить полностью всю стоимость (Full — $ 399.00), обновить ($ 119.00), существует оплата через подписку (помесячно — $ 29.00 в месяц, за год — из расчёта $ 19.00 в месяц).

3.2 Aptana Studio

Бесплатная кроссплатформенная интегрированная среда разработки с открытым исходном кодом для написания веб-приложений. Поддерживает динамическое автодополнение кода для некоторых языков (JS, CSS, HTML).

Помимо перечисленных языков с помощью специальных обновлений позволяет вести разработку в таких языках, как: Python или Ruby.

Рисунок 7 — Рабочий интерфейс Aptana Studio

3.3 Microsoft Visual Studio

Линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, также веб-приложения и веб-сервисы.

Рисунок 8 — Рабочий интерфейс MS Visual Studio

IDE хорошо интегрирована с технологией .NET и содержит компиляторы для всех языков поддерживающих эту платформу. Для разработки веб-приложения имеются интегрированные паттерновые решения, такие как WebForms или MVC. Динамическая система автодополнений кода IntelliSense позволяет писать быстрый и эффективный код.

Для студентов имеется возможность бесплатного использования данного программного продукта.

4. Этапы разработки

4.1 Разработка в WEB

Непосредственный процесс разработки можно разделить на 2 части, а именно: фронтенд и бекэнд.

Таблица 1 — Процессы разработки в WEB

Разберём более подробно а) дизайн проекта — один из ключевых пунктов для большинства веб-проектов, ввиду своей абстрактности не привязан ни к какой из ИТ технологий;

б) вёрстка — вёрсткой в WEB называют процесс преобразования дизайнерского макета в специальную форму, как правило, используются языки разметки из множества XML/SGML (чаще всего (X)HTML) и язык описания стилей CSS;

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

г) разработка базы данных — разработка системы хранения данных, в большинстве случаев используются реляционные СУБД, такие как MySQL, Oracle и MS SQL Server, однако в последнее время всё чаще используются документно-ориентированные СУБД, такие как MongoDB.

д) разработка серверной части — процесс написания серверных приложений по обработке и хранении информации. В отличие от предыдущих веток содержит огромное количество альтернативных технологий, таких как: C#, Perl, PHP, Java, Python, JavaScript и т. д.;

е) системное администрирование — настройка и поддержка серверов.

4.2 Сравнение клиентских технологий

Для написания клиентских (сценарии, которые выполняются непосредственно на компьютере клиента) сценариев можно использовать следующие технологии

а) JavaScript;

б) CoffeeScript;

в) Dart;

г) Flash;

д) Silverlight;

е) ActiveX;

ж) Java.

JavaScript — стандартный язык для большинства браузеров, создавался как простой скриптовый язык для элементарных операций с веб-документом, в качестве замены очень мощному, но тяжёлому механизму Java-апплетов. Со временем развился в полностью самостоятельный язык и сейчас активно используется «вне» браузера.

Таблица 2 — Сравнение JavaScript

CoffeeScript — компилируемый язык для написания клиентских сценариев (компилируется в JS), имеет синтаксис схожий с языками Ruby или Python, используется как правило с платформой RubyOnRails, фактически — это JavaScript. Dart — разрабатываемый компанией Google новый язык для написания клиентских сценариев, по идеологии напоминает Java, но создавался специально для использования в браузере, на данный момент находится в бета-тестировании, но по заявлениям разработчикам, язык призван стать заменой для JavaScript. Flash — универсальная кроссбраузерная платформа и язык (ActionScript) для мультимедии, для оживления веба красочной анимацией, аудио и видео. В отличие от JavaScript, разработчик может быть твёрдо уверен, что его код будет работать как надо, т.к. исходный код Flash сначала компилируется в специальный байт-код, а затем интерпретируется специальной виртуальной машиной на компьютере клиента.

Таблица 3 — Сравнение Flash

Ещё несколько лет назад при сравнении Flash c JavaScript можно было чётко прочертить грань, где и как использовать эти технологии: Flash в большинстве случаев использовался там, где была нужна мощная работа с графикой (например игры), возможность потокового воспроизведение видео и аудио в самом браузере и мощные средства для создания сетевых соединений, в тоже время, т.к. Flash — не общается с браузером на «ты», подобно, как это делает JavaScript, и это рождало множество проблем, тогда и приходил на помощь JavaScript. Однако в связи со стремительным развитием, как самого языка, так и браузеров, современный клиентский JavaScript в 90% случаев может полностью заменить Flash.

Silverlight — технология «клон» Flash от компании Microsoft и ввиду схожести реализации наследует все плюсы и минусы Flash.

ActiveX — технология компании Microsoft, даёт мощный интерфейс для взаимодействия с компьютером пользователя (прямой доступ к файловой системе и т. д.), однако реализация существует только в браузерах InternetExplorer и только под операционной системой Windows, что делает использование затруднительным.

Java — самый популярный язык в мире, взаимодействует с браузером через механизм апплетов, поддерживается большинством браузеров и работает почти в любой операционной системе, однако «тяжесть» и сложность разработки интерфейсов привело к тому, что в контексте «клиентского» кода язык почти не используется.

Вывод: из представленных выше средств конкуренты на данный момент только JavaScript и Flash, однако в последнее время Flash стремительно сдаёт позиции в пользу JS. Возможно, появление языка Dart сможет изменить ситуацию на рынке клиентских языков.

4.4 Взаимодействие интерфейса с сервером

В классической схеме работы любого WEB-приложения лежит один и тот же подход: пользователь задаёт вопрос, а сервер на него отвечает.

Рисунок 9 — Последовательная схема «клиент-сервер»

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

Данная модель не может похвастаться ни интерактивностью, ни скоростью работы. Однако есть способы модернизации: если контекстом исполнения будет не весь документ, а только его часть, т. е. изменяется только то, что должно измениться, а статичная информация остаётся неизменной, то это может существенно ускорить работу и добавить интерактивности нашему интерфейсу.

Для реализации данного подхода можно использовать различные технологии, но на сегодняшний день самой популярной технологией является AJAX, которая основывается на JavaScript и способности браузеров отправлять асинхронные запросы серверу.

4.4.1 Смысл AJAX — в интеграции технологий

Технология AJAX использует комбинацию:

а) (X)HTML, CSS для подачи и стилизации информации;

б) DOM-модель, операции, над которой производятся JS на стороне клиента, чтобы обеспечить динамическое отображение и взаимодействие с информацией;

в) XMLHttpRequest для асинхронного обмена данными с веб-сервером. В некоторых AJAX-фреймворках и в некоторых ситуациях, вместо XMLHttpRequest используется iFrame, SCRIPT-тег или другой аналогичный транспорт;

г) JSON часто используется для обмена данными, однако любой формат подойдет, включая форматированный HTML, текст, XML и даже какой-нибудь EBML.

Рисунок 10 — Определение AJAX

4.4.2 Клиент

В большинстве случаев, компьютер пользователя является средством отображения информации полученной с сервера, так называемый «тонкий» клиент. Это удобно, ведь нет необходимости нагружать клиента лишней для него информации, однако данный подход не всегда может являться рациональным. Некоторые наборы данных могут и должны обрабатываться средствами клиента, тем самым снижая нагрузку на сервер и уменьшая отклик интерфейса, т.к. теперь отпадает необходимость постоянной связи с сервером. Такой подход также позволяет реализовать работы «офлайн» приложения, т. е. при отсутствии подключения к интернету.

4.4.3 Способы хранения данных на клиенте

WebSQL. В HTML 5 есть много новых возможностей, которые позволяют web-разработчикам создавать более мощные и насыщенные приложения. К этим возможностям относятся и новые способы хранения данных на клиенте, такие как WebStorage (или же DOM Storage) и WebSQL database. При этом если WebStorage ориентирован на хранение пар ключ-значение, то в случае WebSQL у нас есть полноценный sqlite (во всех текущих реализациях применяется именно этот движок баз данных, что является проблемой при стандартизации).

Т.е. мы можем хранить данные на клиенте, а также получаем возможность делать динамические выборки с помощью языка SQL. К несчастью, эта технология относительно новая и её поддержкой могут похвастаться лишь новые браузеры. Ситуацию можно немного исправить если в разработке применять плагин к браузерам Gears от Google, однако такой подход породит ряд новых проблем, таких например как: данный плагин нужно скачивать и ставить пользователям, он не реализован во всех браузерах и его разработка остановлена в пользу стандартов HTML5.

Вывод: WebSQL может стать отличным решением, если отбросить поддержку старых браузеров, но всё же отсутствие поддержки в старых браузерах может затруднить разработку.

WebStorage — универсальное хранилище данных на компьютере клиента, оно позволяет хранить данные в виде пар ключ-значение в объёме до 5-ти мегабайт, плюс прибавим к этому неплохую поддержку браузерами (в старых версиях браузеров можно эмулировать работу через Flash/Silverlight или Gears). Данное решение можно использовать для хранения информации, однако отсутствие нативного API для сложных выборок требует использования сторонних библиотек.

Вывод: в совокупности с дополнительной библиотекой может стать универсальным решением.

Cookies — самый старый способ хранения данных на клиенте. Принцип схож с WebStorage, однако сильное ограничение на объём данных делает эту технологию актуальной только для очень маленьких объёмов данных.

4.4.4 Реляционный подход в JavaScript

Рассмотрим следующую структуру данных:

{name: «Андрей «, nick: «Kobezzza» },

{name: «Сергей», nick: «Vantuz» },

{name: «Вася», nick: «Pupkin» }

]

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

Таблица 4 — Пример таблицы данных

Давайте теперь рассмотрим другую комбинацию представления данных:

{

" Kobezzza": {name: «Андрей «, sex: «male» },

" Vantuz": {name: «Сергей», sex: «male» },

" Pupkin": {name: «Вася», sex: «male» }

}

Т.е. мы имеем хеш-таблицу, элементы которой, также являются хешом. Её графическое представление — это двумерная таблица вида:

Таблица 5 -Таблица с первичным ключом

Немного усложним предыдущий пример, и сделаем следующее:

{

" Friends": [

{id: 1, name: «Kobezzza», nick: «Kobezzza» },

{id: 2, name: «Сергей», nick: «Vantuz» },

{id: 3, name: «Вася», nick: «Pupkin» }

],

" Details": {

" 1″: {sex: «male» },

" 2″: {sex: «male» },

" 3″: {sex: «male» }

}

}

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

Таблица 6

В данном примере id можно абстрактно представить, как некий аналог primary key. Таблица Friends имеет отличную от Details структуру, т.к. нам будет удобно использовать методы массивов в JS для сортировки данных и т. д. Т. е. у нас есть главная и дочерняя таблица с установленным отношением «один к одному».

Оперируя данными абстракциями, мы приводим нашу модель данных к реляционную виду.

5. Объектно-ориентированная СУБД на JavaScript

5.1 Фреймворки для работы с данными JS

Для удобного манипулирования с данными в JS существует довольно много различных фреймворков, таких как: JSLINQ, jLinq, JSINQ и т. д.

Все они эксплуатируют одну и ту же реляционную модель, о которой говорилось выше и использует формат JSON для хранения данных, однако интерфейсы для работы с ними у них существенно отличаются, например: JSLINQ предоставляют разработчику интерфейс в виде некоторого множества методов, а JSINQ реализует интерпретатор языка, чем-то похожего на SQL.

Большинство таких фреймворков позиционирует себя как универсальные средства хранения информации, т. е. как на стороне сервера, так и на стороне клиента.

5.2 Collection

На данный момент (актуальная версия 3.7.2) фреймворк реализует полный спектр методов управления данных, а также обзавёлся целым арсеналом методов по работе с шаблонами (компиляция, поддержка рекурсии, реализация БЭМ подхода), а находящаяся в бета стадии версия 4.0 будет включать в себя интерпретатор языка SQL и множество новых инструментов.

В сравнение с другими решениями на JS Collection имеет ряд преимуществ:

а) более высокая скорость работы б) гораздо более мощное API, позволяющее делать перекрёстные запросы и группировки, а также использование статистических функций;

в) независимость структуры данных: Collection реализует интерфейсы для любой нативной JS структуры данных;

г) шаблонизирующий движок;

д) движок контекста следит за целостностью транзакций.

5.2.1 Абстрактная модель Collection

Collection выделяет несколько абстрактных сущностей данных:

а) коллекция — любое JSON подобное дерево, содержащее в себе информацию;

б) контекст — указатель на локальную область коллекции;

в) фильтр — специальная функция, возвращающая логическое значение для каждого элемента коллекции;

г) шаблон — функция, однозначно определяющая строчное представление для каждого элемента коллекции;

д) шаблонные параметры — набор дополнительных параметров шаблонизации;

е) парсер — специальная функция для внесения изменений в результирующую строку шаблона.

Collection может хранить данные любым из возможных для этого способов, а также имеет собственный интерфейс для работы с Local Storage.

5.3 «Карта путей»

На основе созданной СУБД мною была создана новая версия популярного отчёта Яндекс. Метрика «Карта путей».

Рисунок 11 — Карта путей 2.0

Новая версия стала работать в 3 раза быстрее, а конечный код продукта сократился в 5 раз. Этот пример показал эффективность и рациональность подхода использования частичной агрегации данный на компьютере клиента.

На основе созданной СУБД можно создавать приложения любого уровня сложности, где важна скорость ответа данных.

6. Экономико-организационная часть

6.1 Оборудование, необходимое для работы над созданием данного программного продукта

Таблица 8 — Затраты. Для разработки данного программного продукта планируется использование следующего оборудования:

6.2 Определение этапов разработки нового программного продукта

6.2.1 Расчет трудоемкости проекта

Здесь мы произведем структурирование последовательности технической реализации проекта. Произведем планирование содержания работ, формирование последовательности и характеристики этапов выбранных стадий разработки программного продукта.

Таблица 9 — Перечень работ и трудозатраты. Перечень работ и трудозатраты:

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

Общие затраты труда на разработку и внедрение программы определяются следующим образом:

(1)

где t_i — затраты труда на выполнение iго этапа проекта.

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

6.2.2 Определение численности исполнителей

Для оценки возможности выполнения проекта имеющимся в распоряжении разработчика штатным составом исполнителей рассчитывается их средняя численность, которая при реализации проекта разработки и внедрения программы определяется соотношением (2):

(2)

Q_p — затраты труда на выполнение проекта (разработка и внедрение программы), F — фонд рабочего времени.

Величина фонда рабочего времени определяется соотношением (3):

где Т — время выполнения проекта в месяцах, F_M — фонд времени в текущем месяце, который рассчитывается из учета общего числа дней в году, числа выходных и праздничных дней (4):

где t_p — продолжительность рабочего дня, D_K — общее число дней в году, D_BП — число выходных и праздничных дней в году.

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

В соответствии с требованиями кодекса законов о труде РФ (КЗоТ) режим работы фирмы-исполнителя, которая будет заниматься разработкой данного программного продукта, устанавливается с 9.00 до 18.00, пять дней в неделю, обеденный перерыв с 13.00 до 14.00. Выходные дни — суббота, воскресенье и все праздничные дни, указанные в КЗоТ. Работа будет проводиться в течение двух месяцев — с 1 апреля по 31 мая включительно.

Округляем значение N и получаем, что в среднем необходимое количество исполнителей — 2 человека.

Итак, персонал, который будет задействованный в разработке данного программного продукта, состоит из а) руководитель проекта (Р);

б) программист (П).

6.3 Линейный график — график ОКР по созданию новой программной продукции

Линейный график составляется на все виды выполняемых работ в их технологической последовательности. При этом предусматривается возможность параллельного выполнения работ.

Для того чтобы построить график, необходимо определить:

а) сроки разработки, испытаний и внедрений;

б) необходимое количество работников;

в) состав исполнителей.

Таблица 10 — Этапы разработки

6.4 Расчет затрат на новую разработку и расчет цены

Затраты на выполнение проекта состоят из прямых затрат (на заработную плату исполнителям, затрат на закупку или аренду оборудования, затрат на организацию рабочих мест), и косвенных затрат (на так называемые накладные расходы).

(5)

где С_ЗАРП — заработная плата исполнителей, С_ОБ — затраты на обеспечение необходимым оборудованием, С_ОРГ — затраты на организацию рабочих мест, С_НАКЛ — накладные расходы.

Затраты на выплату исполнителям заработной платы линейно связаны с трудоемкостью и определяется следующим соотношением:

(6)

где С_З.ОСН — основная заработная плата, С_З.ДОП — дополнительная заработная плата, С_З.ОТЧ — отчисление с заработной платы.

Расчет основной заработной платы (оплаты труда непосредственных исполнителей) следует проводить по «дневной» оплате труда на основе данных по окладам и графику занятости исполнителей (7):

(7)

где Т_ЗАН — число дней, отработанных исполнителем проекта, О_ДН — дневной оклад исполнителя. При 8-ми часовом рабочем дне он рассчитывается по соотношению (8):

(8)

где О_МЕС — месячный оклад, F_M — месячный фонд рабочего времени (4).

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

О_МЕС — месячный оклад примем:

Таблица 11 — Оклад

Таблица 12 — Расчет заработной платы. Расчет заработной платы:

К расходам на дополнительную заработную плату относятся все выплаты, предусмотренные законодательством за непроработанное время, оплата отпусков, выплата премий и т. д. размер дополнительной заработной платы определяется в процентах и составляет 20% от размера основной заработной платы:

Отчисления с заработной платы состоят в настоящее время в уплате единого социального налога. В соответствии со ст. 241 налогового кодекса РФ налогоплательщик, т. е. работодатель (в данном случае в качестве работодателя выступает заказчик), должен сделать в пенсионный фонд РФ, фонд социального страхования, фонды обязательного медицинского страхования (федеральный и территориальный фонды).

Отчисления с заработной платы составят:

(10)

Таблица 13 — Расчет заработной платы. где Н_СОЦ — отчисления с заработной платы в виде единого социального налога (ЕСН).

Таблица 14 — Расчет заработной платы. Итого общие затраты на заработную плату разработчикам вместе со всеми отчислениями равны:

6.5 Расчет амортизации основных фондов

В соответствии с пунктом 1 статьи 256 Налогового кодекса Российской Федерации (далее НК РФ) амортизируемым имуществом признаются имущество, результаты интеллектуальной деятельности и иные объекты интеллектуальной собственности, которые находятся у налогоплательщика на праве собственности, используются им для извлечения дохода и стоимость которых погашается путем начисления амортизации. Амортизируемым имуществом признается имущество со сроком полезного использования более 12 месяцев и первоначальной стоимостью более 10 000 рублей.

Амортизируемым имуществом также признаются капитальные вложения в предоставленные в аренду объекты основных средств в форме неотделимых улучшений, произведенных арендатором с согласия арендодателя (пункт 1 статьи 256 НК РФ).

В соответствии с пунктом 2 статьи 256 НК РФ не подлежат амортизации следующие виды сдаваемого в аренду амортизируемого имущества:

а) земля и иные объекты природопользования (вода, недра и другие природные ресурсы);

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

в) имущество некоммерческих организаций, полученное в качестве целевых поступлений или приобретенное за счет средств целевых поступлений и используемое для осуществления некоммерческой деятельности;

г) имущество, приобретенное (созданное) с использованием бюджетных средств целевого финансирования, кроме имущества, полученного налогоплательщиком при приватизации;

д) имущество, полученное налогоплательщиком в рамках целевого финансирования;

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

ж) основные средства, полученные организациями, входящими в структуру Российской оборонной спортивно-технической организации (далее РОСТО) (при передаче их между двумя и более организациями, входящими в структуру РОСТО), использованные на подготовку граждан по военно-учетным специальностям, военно-патриотическое воспитание молодежи, развитие авиационных, технических и военно-прикладных видов спорта в соответствии с законодательством Российской Федерации.

В соответствии со статьей 258 НК РФ сроком полезного использования признается период, в течение которого объект основных средств служит для выполнения целей деятельности налогоплательщика.

Срок полезного использования определяется налогоплательщиком на дату ввода в эксплуатацию объекта основных средств в пределах сроков, установленных Классификацией основных средств, утвержденной Постановлением Правительства Российской Федерации от 1 января 2002 года № 1 «О классификации основных средств, включаемых в амортизационные группы». При этом дополнительного обоснования выбора того или иного конкретного срока эксплуатации, принятого для объекта, не требуется.

В соответствии с проектом при разработке данного программного продукта амортизацией будут облагаться следующее оборудование:

Таблица 15 — Амортизация

В соответствии с п. 9 ст. 258 НК РФ основные средства и нематериальные активы включаются в состав амортизируемого имущества с 1-го числа месяца, следующего за месяцем, а котором они были введены в эксплуатацию.

Таким образом, 2 компьютера и МФУ в бухгалтерском учете будут отражены в феврале 2012 года, а в налоговом учете — в апреле 2012 года.

При применении линейного метода, в соответствии с п. 4 ст. 259 НК РФ, амортизации по каждому объекту амортизируемого имущества определяется по формуле: норма К=[1/п] * 100%, где:

К — норма амортизации в процентах к первоначальной (восстановительной) стоимости объекта амортизируемого имущества;

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

За системные блоки Intel Core i7:

а) месячная норма амортизации для целей налогообложения будет рассчитана следующим образом б) К= (1: 36) * 100%=2,8%

в) сумма начисленной в каждом месяце амортизации составит г) 42 500,00 руб. * 2,8% = 1 190 руб.

6.6 Расчет затрат, связанных с организацией рабочих мест для исполнителей проекта

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

В соответствии с санитарными нормами расстояние между рабочими столами с видеомониторами должно быть не менее 2 м., а между боковыми поверхностями видеомониторов — не менее 1,2 м. Площадь на одно рабочее место с терминалом или ПК должна составлять не менее 6 кв.м., а объем — не менее 20 куб.м. Площадь, предусмотренная для размещения одного принтера, соответствует 0,5 площади рабочего места исполнителя. Расположение рабочих мест в подвальных помещениях не допускается. Помещения должны быть оборудованы системами отопления, кондиционирования воздуха или эффективной приточно-вытяжной вентиляцией.

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

Помещение взято общей площадью 16,45 кв.м.

Помещение находится в собственности работодателя — арендная плата отсутствует.

6.6.1 Затраты на электроэнергию

Энергия, которая необходима на производство только данного программного продукта.

Затраты на электроэнергию, в соответствии с нормами Минтруда, рассчитывается по следующей формуле:

где W_{уст.ЭВМ} — устанавливаемая мощность в кВт*ч;

Т_маш. — время работы оборудования;

Т_тариф — стоимость одного кВт*ч (в настоящее время равна 3,80 руб.);

К_у — интенсивность использования энергоустановок (в данном случае Ку=0,85)

6.6.2 Затраты электроэнергии компьютерами:

а) за компьютер:

З Эл.эн.=0,45(кВт*ч)*204ч*3,80(руб/кВт*ч)*0,85 = 348,84 руб. 03 коп.

Где Т_маш = 204 ч. = 8ч.*26дн.

ИТОГО: 348 руб. 84 коп.

6.6.3 Затраты на вспомогательные материалы

Таблица 16 — Затраты

6.6.4 Смета затрат на разработку программного продукта

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

Таблица 17 — Затраты

Цена программного продукта:

Цена = Себестоимость + Прибыль

Себестоимость — часть стоимости готовой продукции (все затраты предприятия на реализацию продукции, выраженные в денежной форме).

Прибыль — 5% от себестоимости.

Ц = 136 693,84+ 136 693,84* 5% = 144 029,66 руб.

Итого: себестоимость данного программного продукта по фактическим затратам на разработку составляет сто сорок четыре тысячи двадцать девять рублей 66 коп.