Я надеюсь, что многие из вас работают с веб-сайтами с высокой посещаемостью, и есть вероятность, что ваши основные проблемы с масштабируемостью находятся в базе данных. Я заметил пару вещей в последнее время:
Большинству больших баз данных требуется команда администраторов баз данных для масштабирования. Они постоянно борются с ограничениями жестких дисков и в итоге получают очень дорогие решения (SAN или большие RAID-массивы, частые окна обслуживания для дефрагментации и перераспределения и т. Д.). Фактическая годовая стоимость обслуживания таких баз данных находится в диапазоне от 100 до 1 млн долларов, что составляет слишком крутой для меня :)
Наконец, у нас есть несколько компаний, таких как Intel, Samsung, FusionIO и т. Д., Которые только начали продавать чрезвычайно быстрые, но доступные SSD-накопители на основе технологии SLC Flash. Эти диски в 100 раз быстрее при случайном чтении / записи, чем лучшие вращающиеся жесткие диски на рынке (до 50 000 случайных операций записи в секунду). Время их поиска практически равно нулю, поэтому стоимость случайного ввода-вывода такая же, как и для последовательного ввода-вывода, что отлично подходит для баз данных. Эти SSD-накопители стоят около 10-20 долларов за гигабайт, и они относительно небольшие (64 ГБ).
Таким образом, представляется, что есть возможность избежать ОГРОМНЫХ затрат на масштабирование баз данных традиционным способом, просто создав достаточно большой массив RAID 5 SSD-дисков (что обойдется всего в несколько тысяч долларов). Тогда нам все равно, фрагментирован ли файл базы данных, и мы можем позволить в 100 раз больше операций записи на диск в секунду без необходимости разбрасывать базу данных по 100 шпинделям. ,
Кто-нибудь еще заинтересован в этом? Я тестировал несколько SSD-дисков и могу поделиться своими результатами. Если кто-нибудь на этом сайте уже решил свои узкие места ввода / вывода с помощью SSD, я хотел бы услышать ваши военные истории!
PS. Я знаю, что существует множество дорогих решений, которые помогают с масштабируемостью, например проверенные временем SAN на основе RAM. Я хочу пояснить, что даже 50 тысяч долларов слишком дороги для моего проекта. Мне нужно найти решение, которое стоит не более 10 тысяч долларов и не требует много времени для внедрения.
Дейв, NXC и Берли,
Спасибо за ваши ответы! Я хотел бы уточнить, что слово «дешево» очень важно в моей ситуации. Итак, я должен использовать дешевые серверы Dell (4 000 2950 долларов, которые имеют только 8 банков памяти). У меня уже установлено 32 ГБ ОЗУ, поэтому я не могу продолжать масштабирование таким образом. Кроме того, добавление ОЗУ не избавит вас от узких мест в WRITE, что сейчас является моей главной проблемой.
Раньше меня интересовало время жизни твердотельных накопителей, но после прочтения современных алгоритмов выравнивания износа я почти уверен, что эти накопители прослужат достаточно долго. Моя база данных записывает 300 ГБ в день, и, согласно прогнозам, в 2009 году она превысит 1 ТБ. Корпоративные твердотельные накопители рассчитаны на обработку около 10 ТБ записей в день в течение нескольких лет.
Я бы не согласился с точкой зрения Берли, что для перехода с SAS на SSD требуется слишком много труда. Моя база данных является синхронным зеркалом, поэтому я могу обновить одну из сторон зеркала, затем наблюдать за ней в течение нескольких месяцев, и, если она выйдет из строя, я могу переключиться на второй сервер, на котором все еще есть старые добрые жесткие диски SAS ...
источник
Ответы:
Потенциальные проблемы
У меня есть пара вопросов по поводу использования SSD для производственных баз данных в настоящее время
Предлагаемые преимущества
Тем не менее, есть ряд пунктов, по крайней мере на бумаге, в пользу SSD в будущем:
Таким образом, для данного эталона производительности, когда вы учитываете общую стоимость владения, включая затраты на прямое питание и косвенное охлаждение, твердотельные накопители могут стать очень привлекательными. Кроме того, в зависимости от особенностей вашей среды, уменьшение количества устройств, необходимых для данного уровня производительности, может также привести к сокращению потребностей в персонале, сокращению трудозатрат.
Стоимость и производительность
Вы добавили, что у вас есть ограничение по стоимости менее 50 000 долларов США, и вы действительно хотите оставить его ниже 10 000 долларов США. Вы также заявили в комментарии, что вы можете получить некоторые «дешевые» SSD, исключая, что SSD будут дешевле, чем администраторы баз данных или консультанты. Это может быть правдой в зависимости от количества часов, в которых вам понадобится администратор базы данных, и от того, будет ли это повторная оплата или нет. Я не могу сделать анализ затрат для вас.
Однако, одна вещь, с которой вы должны быть очень осторожны, это тип SSD, который вы получаете. Не все твердотельные накопители созданы равными. По большому счету «дешевые» твердотельные накопители, которые вы видите в продаже за 200–400 долларов (2008/11/20), предназначены для работы в условиях низкой мощности / нагрева, таких как ноутбуки. Эти накопители на самом деле имеют более низкий уровень производительности по сравнению с жестким диском со скоростью вращения 10 или 15 тыс. Об / мин, особенно для записи. Диски корпоративного уровня, о которых вы говорите, - как и серия Mtron Pro, - достаточно дороги. В настоящее время они вокруг:
В зависимости от вашего места, производительности и требований к резервированию, вы можете легко урезать свой бюджет.
Например, если ваши требования требовали в общей сложности 128 ГБ доступного хранилища, тогда RAID 0 + 1/10 или RAID 5 с 1 горячей точкой будет стоить ~ $ 5600
Однако если вам требуется ТБ доступного хранилища, тогда RAID 0 + 1/10 будет стоить ~ 51 тыс. Долл., А RAID 5 с двумя горячими частями - ~ 32 тыс. Долл.
Большая фотография
При этом для установки, настройки и обслуживания большой производственной базы данных требуется высококвалифицированный специалист. Данные в БД и услуги, предоставляемые из этих данных, чрезвычайно важны для компаний с такими требованиями к производительности. Кроме того, есть много вещей, которые просто не могут быть решены с помощью оборудования. Неправильно сконфигурированная СУБД, плохая схема базы данных или стратегия индексации могут / разрушить / производительность БД. Просто посмотрите на проблемы Stackoverflow, возникшие при их миграции на SQL Server 2008 здесь и здесь., Дело в том, что база данных - это сложное приложение не только на диске, но и на ОЗУ и ЦП. Сложно решить проблему разной производительности, а также целостности данных, безопасности, избыточности и резервного копирования.
Таким образом, хотя я и считаю, что сообщество приветствует любые и все улучшения в аппаратной и программной технологиях, администрирование крупномасштабных баз данных, например, разработка программного обеспечения, представляет собой сложную проблему и для нее по-прежнему требуются квалифицированные специалисты. Данное улучшение может не принести затрат на сокращение труда, на которые вы или компания можете рассчитывать.
Хорошей отправной точкой для некоторых исследований может быть сайт / блог Брента Озара здесь . Возможно, вы узнаете его имя - он тот, кто помогал команде стекопотока в решении проблем с производительностью MS SQL Server 2008. Его блог и ресурсы, на которые он ссылается, предлагают немного широту и глубину.
Обновить
Сами Stackoverflow используют потребительский SSD-маршрут для своего хранилища. Читайте об этом здесь: http://blog.serverfault.com/post/our-storage-decision/
Ссылки
источник
Если у вас есть сайт с действительно большим трафиком, который может использовать SSD для увеличения производительности записи, у вас, вероятно, будут проблемы с временем жизни SSD, поэтому я еще не продал их за это.
Имея это в виду, что делать с базами данных, которые имеют высокий уровень чтения? Ответ прост: закройте сервер настолько большим количеством оперативной памяти, сколько сможете. Вы обнаружите, что самые горячие таблицы почти всегда хранятся в кэш-памяти RAM, и любое большое попадание на диск, вероятно, будет связано с большой таблицей или сканированием индекса, которое часто можно оптимизировать с помощью правильной индексации.
источник
Я работаю в качестве администратора базы данных более 5 лет, и размышления о способах повышения производительности базы данных всегда находятся позади меня. Я наблюдаю за пространством SSD и думаю, что они определенно становятся все более и более жизнеспособным вариантом.
Проверь это;
http://i.gizmodo.com/5166798/24-solid-state-drives-open-all-of-microsoft-office-in-5-seconds
Существует также новый продукт, выпущенный Acard, под названием ANS-9010, который является улучшенной версией GC-Ramdisc, который позволяет использовать оперативную память DDR2 для создания диска SATA (до 64 гигабайт) с использованием палочек DDR2 с теоретической скоростью 400 МБ / с. максимум.
http://techreport.com/articles.x/16255/3
^^ Но еще одна полезная вещь в этой статье заключается в том, что она сравнивает ANS-9010 со всеми игроками на рынке твердотельных накопителей, и выясняется, что у Intel есть 64 ГБ твердотельный накопитель x25-E, что практически сопоставимо с аппаратным виртуальным диском.
То, что меня беспокоит из-за SSD, это изнашивание их со всем стрессом, который переносит большая БД, и поэтому вам придется использовать raid для зеркалирования дисков, что означает, что вы платите вдвое больше;
И недостатком аппаратного виртуального диска является то, что батарея в случае отключения питания заряжает его так долго, что вам придется придумать какой-нибудь причудливый способ ее резервного копирования. Я верю, что вы также можете приобрести для них сетевой штепсель, но это все равно зависит от вашего ИБП.
Я предлагаю вам использовать аппаратный RAM-диск для временного DB и файла подкачки Windows - и поместить базу данных на Intel X25-E Extreme (около 600 долларов США за 64 гигабайта).
В любом случае, это закричало бы и сделало всех нас очень ревнивыми.
(Также рассмотрите возможность использования другого ANS-9010 для размещения сайта)
Ура, Дейв
источник
Мы просто собрали сервер w2k3 r2 64bit Sql 2008 на двойном 2,5-дюймовом гибридном зеркале Seagate Momentus XT - 1/4 такта для ОС и 1/4 такта для БД. Так что использовали 125 ГБ для ОС и 125 ГБ для БД. получали 1500 МБ / с до 1900 МБ / с. На Intel i7 2600K 3,4 ГГц 8 ГБ
источник
На рынке есть продукты, такие как этот, которые делают подобные вещи. Кроме того, как говорит другой автор, добавление дополнительной оперативной памяти на сервер БД даст вам лучшую частоту обращений к кешу, что снизит трафик диска.
Серверы Opteron с 8 разъемами, такие как Sun X4600 , позволят вам разместить до 256 ГБ оперативной памяти по ценам, которые по-прежнему дешевле, чем большая команда администраторов баз данных. Вы также можете рассмотреть возможность использования плоских файлов, а не СУБД (как это сделала эта компания ), что даст вам лучшую производительность, чем СУБД. В этом случае SAN обеспечит вам степень целостности данных. Однако вам придется тщательно разработать стратегию доступа к данным, чтобы не оказаться в беспорядке. По-видимому, это делают довольно много крупных доткомов. Это значительно более эффективно, чем СУБД, что позволяет довольно пешеходному оборудованию справляться с большими нагрузками и позволяет избежать лицензионных отчислений СУБД.
источник
Диски SSD основаны на флэш-памяти NAND (MLC или SLC). Если вы покупаете SSD-диски в форм-факторе SATA (2 или 3), вы ограничиваете производительность, которую вы можете получить от них. Как правило, SSD-накопители на базе быстрого контроллера Sandforce SF-1200 производят 220 МБ / с и 205 МБ / с, что намного быстрее, чем у старомодного механического вращающегося диска.
Однако, если вы переходите на решение PCIe, такое как FusioIO, в котором нет медленного разъема SATA 2 или SATA 3, вы ищете решения, которые в 10-50 раз быстрее вращающихся механических быков (я имею в виду диски).
Поэтому для вашего «дешевого» решения используйте SATA 2/3 SDD на базе контроллера Sandforce SF-1200. Это позволит вам увеличить скорость примерно в 3-5 раз (основываясь на реальном опыте). Если у вас есть бюджет, то перейдите на FusioIO. Ничто не побьет это с точки зрения производительности. Это безумно быстро. Ожидайте потратить от 20 000 до 50 000 долларов.
источник