Эти реалии привели к созданию новых структур баз данных. Старые принципы создания записей и предопределенных полей, отражающих четко заданную иерархию информации, остались в прошлом. Долгое время самым распространенным языком доступа к базе данных был SQL («структурированный язык запросов»). Само название говорит о его жесткости. Но в последние годы произошел переход в сторону так называемой технологии NoSQL, при которой в базах данных не требуется предопределенная структура записей. Допускаются данные различного типа и размера. При этом они все так же доступны для поиска. Беспорядок, который допускается в структуре таких баз данных, компенсируется тем, что для их хранения и обработки требуется больше ресурсов. И все же, учитывая резкое падение затрат на хранение и обработку, этот компромисс мы можем себе позволить.
Пэт Хеллэнд, один из ведущих мировых авторитетов по вопросам проектирования баз данных в корпорации Microsoft, в статье «Если у вас слишком много данных, то и “достаточно хорошо” — уже хорошо» (If You Have Too Much Data, then ‘Good Enough’ Is Good Enough) описывает это явление как фундаментальный переход. Определив несколько основных принципов традиционного проектирования баз данных, которые были подорваны беспорядочными данными различной точности и происхождения, он изложил такие выводы: «Мы больше не можем претендовать на то, чтобы жить в чистом мире [информации]. Обработка больших данных влечет за собой неизбежные потери информации. Зато вы получаете быстрый результат». «Не страшно, если мы получаем ответы с потерями, — зачастую это вполне соответствует бизнес-потребностям», — подытожил Хеллэнд.
Традиционное проектирование баз данных обещает стабильное получение единообразного результата. Спрашивая у бухгалтера о состоянии баланса, вы ожидаете получить точную сумму. А повторив свой запрос через несколько секунд, вы хотели бы, чтобы система выдала такой же результат при условии, что ничего не изменилось. Однако по мере роста объема данных и увеличения количества пользователей, имеющих доступ к системе, поддерживать такое единообразие становится все труднее.
Большие наборы данных не хранятся централизованно. Как правило, они распределяются между несколькими жесткими дисками и компьютерами. Для обеспечения надежности и скорости запись может храниться в двух или трех разных расположениях. Если обновить запись в одном расположении, то данные в других расположениях будут считаться неправильными, пока их тоже не обновят. Традиционным системам было свойственно ожидать завершения всех обновлений. Но это менее практично, когда данные широко распространены, а сервер атакуется десятками тысяч запросов в секунду. В таком случае беспорядочность — неплохое решение.
