Наш удаленный офис состоит из 30 человек. Работа связана исключительно с SEO под США. А это предполагает, что денно и нощно — так как работники разбросаны по разным временным поясам — мы ищем и находим сотни ссылок, контактов, характеристик. Информация собирается лавинообразно, в день таблицы увеличиваются на 1200-3000 ячеек. Умножьте это на полгода работы… Уже сегодня голова идет кругом.
Я думаю, что любая виртуальная компания подобного типа, которая работает с большим объемом данных, на определенном этапе задумывается о смене формата их хранения. В данной заметке я хочу затронуть проблему, описанную в сабже, и обсудить с комментаторами вопросы, вынесенные в конец материала. Заранее извиняюсь за отсутствие деталей, не можем вынести все самое вкусное на всеобщее обсуждение.
Сделаем флешбек на полтора года назад. Когда во главе команды стоит один человек (в данном случае я), возлагающий на себя абсолютно все обязанности, он без проблем управляется со всем своим «богатством» через Microsoft Excel. Будь то ссылки, email-адреса, телефоны или другая информация — старый добрый «Эксель» устроен так, что проблем с его освоением не возникает. Если поначалу руки растут не из того места, ничего страшного — со временем все важные функции осваиваются по мере надобности.
Изначально было не так и сложно копировать ячейки из одной вкладки в другую. Этот «мартышкин труд» не напрягал и даже в некоторой степени увлекал. Все данные умещались в одном-единственном файле, разбитом на вкладки. Та информация, которая скапливалась и хранилась в архивных целях (то бишь, активный доступ к ней не предполагался) выносилась в дополнительный файл. На дворе был 2010-й год.
Взглянем на то, как за год работы одного человека возросли объемы данных.
В результате образовалось 3 файла, суммарный объем которых не превышал 100 тыс. заполненных ячеек.
Когда работать одному стало невмоготу, решили собрать виртуальный офис, где, как и положено, каждый будет выполнять свой спектр работ.
Наступил 2011-й год… Незамедлительно было принято решение перенести все базы на Google Docs, чтобы обеспечить одновременное редактирование документов. Основных мотивов для перехода на онлайн-платформу не так много. Но, согласитесь, они перевешивают все остальное:
Найти другую онлайн-альтернативу Google Docs было можно, но не нужно (извините за косноязычие). Лучше ничего и не было, да и нет. Мы не будем здесь обсуждать все возможные варианты, которые мы протестировали, чтобы не бросать тень на альтернативные бесплатные сервисы. Вывод один: их не много, все они функционально отстают от Google Docs. Если кто-то не согласен, отпишите, пожалуйста, в комментариях. Автор может ошибаться.
Однако ложка дегтя нашлась, и не одна, а целый черпак. Очень быстро стали выявляться недостатки Google Docs по отношению Excel, и помимо этого. Документов, с которыми работали активно, со временем становилось все больше, их стала порядка 10. Каждый день документы пополнялись на 500-1000 строк, а это еще нужно умножить на 2, чтобы получить количество заполняемых ячеек. И тут лимиты Google Docs дали о себе знать. 400тыс. ячеек, господа, не более.
К сожалению, это еще не все неудобства. Что еще?
Чтобы не быть голословным, передам слово коллегам. Вот на что они жалуются:
Артур:
Раздражает лимит в 400 000 ячеек
Тормоза, сегодня вообще невозможно пользоваться доками, просто не грузятся
Паша:
Ага меня тоже клинит. что не могу больше 1000 ссылок добавить в док
Игорь:
В доках всегда смущают и раздражают лаги и эроры частые! + не перенести больше 1000 ячеек одновременно.
Ольга:
На данный момент в Google Docs неудобно:
1. Перенос из дока в док — приходится удалять, переносится только по вкладкам.
2. При поиске, если не находит в одном документе, или для подстраховки приходится искать поочередно в 3х-4х документах. Если переход на SQL даст возможность объединить все данные в одну базу, это ускорит поиск и поможет избежать дублей!!!
Ну и сегодня после 13.00 гуглдоки просто отказались работать. Лада: «не перенести больше 1000 ячеек одновременно.». У меня вчера даже шесть ячеек перенести не получалось) На десерт — две рядовых проблемы:
И раз...
И два...
2011-й год, июнь. Хранить данные в таблицах становится все сложнее. Кроме того, поджимают лимиты Google Docs: нам приходится создавать новые документы, а работающим с почтой — прыгать из одного дока в другой. Вчера два дня подряд отдельные сотрудники и вовсе не могли достучаться до небес.
Разбивать документы на более мелкие — не лучшее решение: приходится открывать по несколько документов, и в каждом из них искать нужную информацию. А если есть дубли? Каждую ссылку не проверишь по 2 раза.
Оля:
я сейчас каждую ссылку прогоняю по файлам «упр.почтой», «упр. почтой2» и «второй прогон», иногда еще и «обзвон и письма» для проверки, в общем пару минут занимает, вместо поиска в несколько секунд по одному объединенному документу.
Представьте, что в идеале на один ручной поисковый запрос (URL, email) в документ уходит 10 секунд (это при учете того, что окно поиска открыто регулярно). Это без учета того, что он еще и спину почешет, и зевнет, перед тем, как приступить к поиску.
Даже 10 минут экономии в день — это выигрыш в 4 часа времени в месяц (10 минут умножаем на 22 рабочих дня). Если перемножить еще на 10 (количество работников, активно использующих поиск в Google Docs), без экономии этих секунд «в трубу» улетает 40 рабочих часов. А оплата у нас, фактически, почасовая.
Все вышесказанное наводит на мысли о том, что для всей информации нужна единая база с разбиением на категории, а не файлы. Что я имею в виду? Смена категории должна производиться двумя кликами, а не телодвижениями вроде: скопировать ячейку (еще попробуй с первого раза попасть в нужную область), вставить в другой документ, удалить из старого. Да, пока Google Docs не научился вырезать информацию из одной вкладки в другую, только в пределах одной книги. А еще дурацкая активация гиперссылок принуждает чистить документы от активных URL'ов регулярно. В общем, начинает выводить из себя любая мелочь. Или вот еще пример.
Я давно предлагал начальнику начать хранить данные не в Excel или Google Docs, а в SQL. Сейчас у нас десятки тысяч строк с различными данными. Все это более-менее приведено к единому формату: дата, URL, comment и т. д. Поэтому мы можем бескровно перенести все, что у нас скопилось, в единую SQL-БД.
Но в чем проблема? SQL в виде базы данных не откроешь в Блокноте, не станешь редактировать вручную. С одной стороны, БД будет посложнее в освоении, с другой стороны, как сделать хранение данных простым и общедоступным. Нужна «человеческая» оболочка, UI, причем «заточенная» именно под наши нужды. Собственно, вот они, наши требования:
Разумеется, это еще не все требования, однако уже сегодня этого катастрофически не хватает в том же Google Docs.
Предположительно, SQL-база может работать под управлением CMS Drupal. Почему Drupal? Для нее написано определенное количество модулей, которые мы сможем применить под наши нужды (хотя бы пару из них, остальное напишется потом). У этой CMS большое сообщество, русскоязычное в том числе. Масштабируемость нагрузки и прочие плюшки рилагаются.
Но и тут — проблема. Мы не хотим изобретать новый велосипед. Все-таки, решение кардинальным образом скажется на производительности всего многочисленного офиса. Как бы не вышло так, что, перенеся все данные на Drupal, нам не пришлось бы потом все переносить все обратно, посыпая голову пеплом? Потом еще меня индивидуально будут долго и мучительно наказывать за то, что я предложил такое решение. Как начальство, так и подчиненные.
Итак, нужна помощь знатоков. Предлагаю на обсуждение следующие вопросы:
Заранее благодарю за любые советы.
Я думаю, что любая виртуальная компания подобного типа, которая работает с большим объемом данных, на определенном этапе задумывается о смене формата их хранения. В данной заметке я хочу затронуть проблему, описанную в сабже, и обсудить с комментаторами вопросы, вынесенные в конец материала. Заранее извиняюсь за отсутствие деталей, не можем вынести все самое вкусное на всеобщее обсуждение.
Microsoft Excel
Сделаем флешбек на полтора года назад. Когда во главе команды стоит один человек (в данном случае я), возлагающий на себя абсолютно все обязанности, он без проблем управляется со всем своим «богатством» через Microsoft Excel. Будь то ссылки, email-адреса, телефоны или другая информация — старый добрый «Эксель» устроен так, что проблем с его освоением не возникает. Если поначалу руки растут не из того места, ничего страшного — со временем все важные функции осваиваются по мере надобности.
Изначально было не так и сложно копировать ячейки из одной вкладки в другую. Этот «мартышкин труд» не напрягал и даже в некоторой степени увлекал. Все данные умещались в одном-единственном файле, разбитом на вкладки. Та информация, которая скапливалась и хранилась в архивных целях (то бишь, активный доступ к ней не предполагался) выносилась в дополнительный файл. На дворе был 2010-й год.
Google Docs
Взглянем на то, как за год работы одного человека возросли объемы данных.
1 вкладка (.xls, Excel) => 10 вкладок (.xls, Excel) => 5 файлов (.xls, Excel)
В результате образовалось 3 файла, суммарный объем которых не превышал 100 тыс. заполненных ячеек.
Когда работать одному стало невмоготу, решили собрать виртуальный офис, где, как и положено, каждый будет выполнять свой спектр работ.
Наступил 2011-й год… Незамедлительно было принято решение перенести все базы на Google Docs, чтобы обеспечить одновременное редактирование документов. Основных мотивов для перехода на онлайн-платформу не так много. Но, согласитесь, они перевешивают все остальное:
- Возможность совместной работы
- Надежность хранения
- Бесплатность
Найти другую онлайн-альтернативу Google Docs было можно, но не нужно (извините за косноязычие). Лучше ничего и не было, да и нет. Мы не будем здесь обсуждать все возможные варианты, которые мы протестировали, чтобы не бросать тень на альтернативные бесплатные сервисы. Вывод один: их не много, все они функционально отстают от Google Docs. Если кто-то не согласен, отпишите, пожалуйста, в комментариях. Автор может ошибаться.
Однако ложка дегтя нашлась, и не одна, а целый черпак. Очень быстро стали выявляться недостатки Google Docs по отношению Excel, и помимо этого. Документов, с которыми работали активно, со временем становилось все больше, их стала порядка 10. Каждый день документы пополнялись на 500-1000 строк, а это еще нужно умножить на 2, чтобы получить количество заполняемых ячеек. И тут лимиты Google Docs дали о себе знать. 400тыс. ячеек, господа, не более.
К сожалению, это еще не все неудобства. Что еще?
- Нет многих нужных опций (удаление дублей, нельзя выделять часть текста в ячейках и подобные жизненно важные мелочи)
- По сравнению с Excel, уменьшилась скорость копирования ячеек и перехода из одного документа в другой, раза в 2.
- Интернет-зависимость (в прямом смысле) и потребление трафика. Нет Интернета — нет доступа к данным.
- Поскольку мы работаем с URL'ами, приходится вычищать документы от гиперссылок.
Чтобы не быть голословным, передам слово коллегам. Вот на что они жалуются:
Артур:
Раздражает лимит в 400 000 ячеек
Тормоза, сегодня вообще невозможно пользоваться доками, просто не грузятся
Паша:
Ага меня тоже клинит. что не могу больше 1000 ссылок добавить в док
Игорь:
В доках всегда смущают и раздражают лаги и эроры частые! + не перенести больше 1000 ячеек одновременно.
Ольга:
На данный момент в Google Docs неудобно:
1. Перенос из дока в док — приходится удалять, переносится только по вкладкам.
2. При поиске, если не находит в одном документе, или для подстраховки приходится искать поочередно в 3х-4х документах. Если переход на SQL даст возможность объединить все данные в одну базу, это ускорит поиск и поможет избежать дублей!!!
Ну и сегодня после 13.00 гуглдоки просто отказались работать. Лада: «не перенести больше 1000 ячеек одновременно.». У меня вчера даже шесть ячеек перенести не получалось) На десерт — две рядовых проблемы:
И раз...
И два...
К чему мы пришли, или кризис среднего возраста
5 файлов (.xls, Excel) => 20 файлов Google Docs => ??? :(
2011-й год, июнь. Хранить данные в таблицах становится все сложнее. Кроме того, поджимают лимиты Google Docs: нам приходится создавать новые документы, а работающим с почтой — прыгать из одного дока в другой. Вчера два дня подряд отдельные сотрудники и вовсе не могли достучаться до небес.
Разбивать документы на более мелкие — не лучшее решение: приходится открывать по несколько документов, и в каждом из них искать нужную информацию. А если есть дубли? Каждую ссылку не проверишь по 2 раза.
Оля:
я сейчас каждую ссылку прогоняю по файлам «упр.почтой», «упр. почтой2» и «второй прогон», иногда еще и «обзвон и письма» для проверки, в общем пару минут занимает, вместо поиска в несколько секунд по одному объединенному документу.
Представьте, что в идеале на один ручной поисковый запрос (URL, email) в документ уходит 10 секунд (это при учете того, что окно поиска открыто регулярно). Это без учета того, что он еще и спину почешет, и зевнет, перед тем, как приступить к поиску.
Даже 10 минут экономии в день — это выигрыш в 4 часа времени в месяц (10 минут умножаем на 22 рабочих дня). Если перемножить еще на 10 (количество работников, активно использующих поиск в Google Docs), без экономии этих секунд «в трубу» улетает 40 рабочих часов. А оплата у нас, фактически, почасовая.
Куда мы идем?
Все вышесказанное наводит на мысли о том, что для всей информации нужна единая база с разбиением на категории, а не файлы. Что я имею в виду? Смена категории должна производиться двумя кликами, а не телодвижениями вроде: скопировать ячейку (еще попробуй с первого раза попасть в нужную область), вставить в другой документ, удалить из старого. Да, пока Google Docs не научился вырезать информацию из одной вкладки в другую, только в пределах одной книги. А еще дурацкая активация гиперссылок принуждает чистить документы от активных URL'ов регулярно. В общем, начинает выводить из себя любая мелочь. Или вот еще пример.
Мы должны отказаться от таблиц в их Exel'eвской и GDocs'овской сущности.
Я давно предлагал начальнику начать хранить данные не в Excel или Google Docs, а в SQL. Сейчас у нас десятки тысяч строк с различными данными. Все это более-менее приведено к единому формату: дата, URL, comment и т. д. Поэтому мы можем бескровно перенести все, что у нас скопилось, в единую SQL-БД.
Но в чем проблема? SQL в виде базы данных не откроешь в Блокноте, не станешь редактировать вручную. С одной стороны, БД будет посложнее в освоении, с другой стороны, как сделать хранение данных простым и общедоступным. Нужна «человеческая» оболочка, UI, причем «заточенная» именно под наши нужды. Собственно, вот они, наши требования:
- Через поиск мы сможем найти все, что нам нужно: от наличия ссылки в блеклисте (blacklist) до ссылки в отчетах (whitelist). Это уменьшает вероятность повторной отправки письма клиенту и дублей соответственно. С помощью фильтров поиска можем отсеивать ссылки в базе по заданному критерию.
- В столбцах мы можем указывать все что нам угодно, и строки не будут расползаться на весь экран. Работники смогут экспортировать/импортировать данные в SQL-формате,
- Строки таблицы будут «именными»: содержать запись о том, что именно Иванов нашел информацию, повлекшую за собой (не-)приятности. Таким образом, мы сможем проследить судьбу каждой ссылки.
- Управление с помощью планировщика Cron, который сможет по расписанию делать со ссылками все, что нам угодно: перепроверять PR и Ext. links. Фактически, отпадает нужда в скриптах Google Docs.
- В SQL нет таких лимитов, как в Google Docs. Базы хватит нам на всю жизнь.
- Удобный Backup в пару кликов.
- Для того, чтобы перенести строку из одной инстанции в другую, нам не нужно будет прыгать между файлами. Меняем категорию для ссылок (можно с помощью флажков) — и готово. Пример? Проделали над ссылками работу — поменяли категорию на «XXX». Обзвонщики открывают свою категорию XXX (выводится список их категории). Если ссылка больше не интересует- меняем категорию на Blacklist и редактируем примечание. И так далее.
- Быстрый импорт/экспорт. Например, мы можем сортировать данные по нужным параметрам в пару кликов мыши, экспортировать таблицы в CSV, всего лишь щелкнув на значок.
Разумеется, это еще не все требования, однако уже сегодня этого катастрофически не хватает в том же Google Docs.
Предположительно, SQL-база может работать под управлением CMS Drupal. Почему Drupal? Для нее написано определенное количество модулей, которые мы сможем применить под наши нужды (хотя бы пару из них, остальное напишется потом). У этой CMS большое сообщество, русскоязычное в том числе. Масштабируемость нагрузки и прочие плюшки рилагаются.
Но и тут — проблема. Мы не хотим изобретать новый велосипед. Все-таки, решение кардинальным образом скажется на производительности всего многочисленного офиса. Как бы не вышло так, что, перенеся все данные на Drupal, нам не пришлось бы потом все переносить все обратно, посыпая голову пеплом? Потом еще меня индивидуально будут долго и мучительно наказывать за то, что я предложил такое решение. Как начальство, так и подчиненные.
Итак, нужна помощь знатоков. Предлагаю на обсуждение следующие вопросы:
- Какая СУБД лучше всего подходит для хранения больших объемов информации, в районе 10 млн. ячеек и более. MySQL? Oracle?!
- Управление БД посредством Drupal — насколько оно эффективно?
- Какие решения, помимо баз данных, можно использовать в сравнительно небольшой компании?
- Есть ли смысл содержать программиста Drupal на постоянной основе? Поначалу можем переместить только часть данных в SQL, а что-то хранить в GDocs, например, отчеты.
Заранее благодарю за любые советы.
