Этой весной команда «Рэйдикс» подготовила и выпустила первую версию ПО для создания распределенной блочной СХД, работающей на серверных платформах «Эльбрус-4.4» на базе микропроцессоров «Эльбрус-4С».
Полезность такого симбиоза видна невооруженным взглядом — сборка СХД на базе отечественного железа и отечественной операционной системы становится вполне привлекательным продуктом внутреннего рынка, в частности для заказчиков, имеющих фокус на импортозамещение.
Читать полностью »
Заметил за собой, что постоянно записываю всякие мелочи, полезную информацию, просто что-то из буфера обмена прямо в текстовом редакторе. Всегда где-то на фоне висит открытый Sublime Text с кучей вкладок.
И ещё я заметил, что мне удобнее всего структурировать информацию в одном файле используя синтаксис Markdown — приятнее именно исходный текст, а не результат, отображаемый на том же гитхабе.
Со временем я заметил, что таких сохраненных файлов накопилось немало, да и незакрытые вкладки убавляться не собираются. А ведь одно неосторожное движение и вся не сохранённая накопленная информация канет в небытие, да и с других устройств не посмотришь, и раскидывать по папочкам тоже не очень удобно.
Всё это привело меня к мысли написать что-то вроде своего движка для хранения всей информации в одном месте и в удобном виде. Да-да, есть куча всяких Evernote, каких-нибудь заметок, встроенных в MacOS/iOS и так далее, которые и синхронизируются, и фичи полезные имеют — но, как говорится, хочешь сделать что-то хорошо (для себя), сделай это сам. Да и, как почти любой программист, в любой непонятной ситуации я беру и пишу всё сам. Так вышло и в этот раз.
В последние 10 лет ВТБ переживает мощный рост вычислительной нагрузки. Каждый год она увеличивалась в полтора раза, а объем учетных данных — в два. Службы поддержки очень старались, но угнаться за этими темпами было непросто: планы запросов отъезжали, дисковое пространство заканчивалось, обновления прикладного кода съедали все ресурсы. В этом посте мы расскажем, как решили проблему без больших трат на еще один IBM System p.
При проектировании веб-приложения чрезвычайно важно выбрать подходящие средства для локального хранения данных. Речь идёт о механизме, который позволит надёжно хранить информацию, будет способствовать снижению объёма данных, передаваемых между серверной и клиентской частями приложения, и при этом не ухудшит скорость реакции приложения на воздействия пользователя. Хорошо продуманная стратегия локального кэширования данных является центральным звеном в разработке мобильных веб-приложений, которые могут работать без подключения к интернету. Современные пользователи всё чаще и чаще относятся к подобным возможностям как к чему-то привычному и ожидаемому.
Сегодня, в переводе 16 части серии материалов, посвящённых всему, что связано с JavaScript, мы поговорим о механизмах хранения данных на стороне клиента, которые могут использоваться в веб-разработке, и о выборе системы хранения данных для конкретного проекта.
Читать полностью »
В конце прошлого месяца 2ГИС начал отображать подъезды. Входы в организации мы показываем аж с 2013 года, а подъезды — вроде бы те же входы. Так почему только сейчас? Все внутренние продукты и процессы готовы, всего-то нужно дособрать ещё чуть-чуть да подправить отображение в UI.
Кроме стандартного ответа «Были другие приоритеты» есть и не совсем стандартный: «Не всё так просто». Эта статья про то, какие были сложности и как мы их решили.
Читать полностью »
GraphQL — это стандарт декларирования структур данных и способов получения данных, который выступает дополнительным слоем между клиентом и сервером. Если вы впервые слышите о GraphQL, то вот пара хороших ресурсов: раз и два.
В этой статье я расскажу как вы можете использовать GraphQL в своих проектах на технологиях InterSystems.
Привет! Меня зовут Сергей, я работаю главным инженером в Сбертехе. В ИТ-сфере я примерно 10 лет, из которых 6 занимаюсь базами данных, ETL-процессами, DWH и всем, что связано с данными. В этом материале я расскажу о Vertica — аналитической и по-настоящему колоночной СУБД, которая эффективно сжимает, хранит, быстро отдает данные и отлично подходит в качестве big data решения.
Привет! Мы закрываем сезон Университетов DataLine семинаром в Санкт-Петербурге.
28 июня ждем вас на семинар «Виртуальная инфраструктура для разработчиков: возможности, приложения и сервисы». Поговорим о том, как облачная инфраструктура и сервисы могут быть полезны разработчикам. Рассмотрим примеры развертывания тестовых сред и работу с контейнерами и приложениями.
Осталось всего несколько мест, регистрация обязательна!
Читать полностью »
Компания Huawei Technologies, известная прежде всего как поставщик сетевого и телекоммуникационного оборудования, более пяти лет назад начала мощный натиск на мировой серверный рынок, нацеливаясь на повышение узнаваемости своего бренда среди корпоративных заказчиков серверов. Кроме того, компания пытается создать себе преимущества благодаря внушительным инвестициям в исследования и разработку.
Предмет сегодняшнего обзора — двухсокетный стоечный сервер 2U Huawei RH2288 V3. Как считает производитель, его основная задача — обработка и хранение данных ответственных приложений в небольшом стоечном пространстве. Серверы Huawei RH2288 V3 подойдут для работы с интернет-приложениями и важными корпоративными системами, для обработки и хранения больших данных, облачных вычислений, предоставления телекоммуникационных услуг. Их применяют поставщики услуг хостинга и VPS, например, RUVDS — официальный партнёр Huawei.
Elasticsearch, Kibana и Logstash (ELK) – отличный набор инструментов для сбора и визуализации большого количества данных.
Логи, журналы, события – всё это довольно легко собирается, мапится и отображается в едином инструментарии. Logstash мапит данные, Elasticsearch хранит их, а Kibana отображает в виде графиков.
При всей мощи этой связки, естественно, есть задачи, которые невозможно реализовать через встроенные возможности.
Например, Kibana прекрасно показывает данные в рамках одной таблицы (индекса), но как только дело доходит до объединения разных индексов в одну выборку, она беспомощно разводит руки.
И единственный способ решить задачу в этом случае – выгрузить данные из Kibana и объединить их в любом другом средстве, например, в Excel.
Простой пример. Представьте, что Ваша Ёлка (ELK) собирает и хранит события Jira – по любому изменению любой из задач таск-трекера.
В этом случае в индексе Elasticsearch по одной задаче будет храниться несколько записей:
