Привет, меня зовут Евгений Думчев, я разработчик в DD Planet. Сегодня хочу поделиться опытом подключения платежного шлюза Сбера, чем мы занимались в рамках одного из проектов. Кажется, это будет полезная история, ведь в нынешние непростые времена многие из нас задумываются о том, чтобы открыть свой «маленький свечной заводик» – какой-нибудь небольшой бизнес на черный день. Тортики там печь, платы паять, в общем, что-нибудь, что бы обеспечило дополнительный доход. Раньше для коммерции подобных сайд-проектов не требовалось ничего, кроме условного Пейпала (к тому же он расширял географию продаж). А теперь волей-неволей приходится задумываться об отечественных решениях для проведения оплат.
Платежный шлюз – как раз такое решение. И оно на самом деле очень простое, любой посетитель Хабра, скорее всего, сможет его развернуть, достаточно хотя бы примерно представлять устройство REST API. В этой статье я расскажу, как подключить и настроить шлюз от Сбера – но в принципе эта инструкция пригодится со шлюзом от любого банка.
Современные технологии позволяют диджитал-потребителям быстро получать доступ к информации, продуктам и услугам. Поэтому компании нуждаются в технологиях обработки данных в режиме реального времени, чтобы оставаться конкурентоспособными и не отставать от своих клиентов.
Несмотря на то, что MongoDB начало движение в сторону строгости реляционной модели, она по прежнему остается документной БД и предполагает возможность сохранения документов произвольной структуры. И при использовании MongoDB в языках с динамической типизацией (JavaScript, Python) сохранение или генерация объектов не вызывает сложностей, поскольку заранее не требуется определить структуру извлекаемого или сохраняемого объекта. Но как действовать в случае использования драйверов для MongoDB для языков со строгой типизацией?
В этой статье мы разберем приемы для работы с неструктурированными данными, которые позволят сохранить преимущества использования сериализации с механизмами рефлексии для извлечения произвольных документов.
Можно ли найти конкретного человека, жившего в XVII веке? Выражаясь современным языком «пробить по базам». Оказывается, архивные документы хранят массу информации об обычных людях того периода. Однако существует ряд сложностей, не позволяющих обычному исследователю добраться до этой информации. Во-первых, нужно пройти определённую процедуру по получению доступа в архив. Во-вторых, не всегда можно выйти на нужный документ, используя так называемый научно-справочный аппарат – различные описи и реестры документов, имеющиеся в архиве. Наконец, не имея навыков чтения документов XVII века, которые написаны скорописью, почти нереально ознакомиться с его содержанием.
Данные проблемы предполагается решить с помощью создания базы данных служилых людей XVII века. Об этом небольшая история.
Как всё начиналось.
Привет! Меня зовут Дмитрий и вот уже более 10 лет я изучаю историю южных уездов России XVII века. Территориально – это современные Белгородская, а также соседние Воронежская, Курская, Липецкая и другие области. Населены они были тогда так называемыми служилыми людьми – они получали здесь в качестве служебного жалования земельные наделы, которые сами и обрабатывали. В XVIII веке их потомки стали однодворцами, а затем государственными крестьянами. Большая часть населения Курской, Воронежской и соседних губерний XIX века происходят из тех самых служилых людей XVI–XVII веков.
Если вы столкнулись с задачей хранения сильно связанных данных, то отличным вариантом будет использовать графовую модель данных. Мы в Текфорс сделали именно так. Почему - разберем в этой статье.
Всем добрый день.
В своей предыдущей статье я уже упомянул о разрабатываемой нами системе, которая решает, казалось бы, не решаемую задачу - а именно автодискавери сетевых элементов в сетях телеком операторов, построение топологий, поиск путей прохождения трафика на основе информации, полученной из самих сетевых элементов. При этом стоит уточнить, что система не нуждается в интеграции со сторонними системами управления, такими как NCE (бывший Huawei u2000 TN), SoEM (СУ Ericsson), Aviat Provision, NFM-P (Nokia), и любыми другими. Т.е. система самодостаточна и способна работать в полностью автономном режиме.
Начну с той проблемы, которая возникла много десятилетий тому назад - и название этой проблемы - актуальная информация о состоянии сетей в режиме он-лайн. Дело в том, что мультисервисные сети давно стали мультивендорными - т.е. в каком-то филиале N любого провайдера связи, с течением времени скопилось множество разновендорного оборудования - сети MEN построены на Cisco, Huawei, Nokia. РРЛ - NEC, Huawei, Nokia и т.д. до бесконечности и в разных последовательностях. И т.к. каждый вендор не стремится создать универсальную СУ, которая могла хотя бы нарисовать топологию мультивендорной сети, приходится изобретать велосипед раз за разом.
Чаще всего велосипеды получались не далеко едущими, одноколесными, неудобными, без сидения или колес. Даже в системах управления крупных вендоров, функциональность не блистала. Более менее вменяемое я увидел в СУ Huawei - NCE. Но опять таки - каждый домен типов оборудования на своих вкладках, и единую топологию не получить - т.е. нельзя отобразить единовременно и на одной подложке сеть MBH (MEN+RRL). Не говоря уже о единовременном отображении специфических проблем, за которыми следят операторы связи - высокая утилизация интерфейсов, BBE/ES/SES/UAS, FCS, RSL Low, QoS Drop по очередям и пр.
Загрузить миллион записей в питон за секунду?
Нет. Получилось еще быстрее!
У меня есть небольшое хобби - я экспериментирую с машинным обучением применительно к торговле на бирже, в частности, с криптовалютами. После различных наколенных экспериментов я захотел создать удобный инструмент - базу торговых котировок. В процессе работы необходима быстрая загрузка достаточно большого количества данных. Это необходимо для расчетов, генерации данных для обучения, бэк-тестинга и других задач. Количество записей, которые нужно загрузить в питон довольно велико - речь может идти о миллионах и более записей.
В этом материале вы узнаете, как создать Telegram-канал, который будет сам обновляться, получая данные из открытых источников. Используем Python, AWS Lambda, DynamoDB и BeautifulSoup.
Apache Cassandra - это распределенная NoSQL база данных. В этой статье будут описаны основные механизмы передачи, репликации и поддержания согласованности данных внутри сети.
В первой статье из серии об использовании Apache Cassandra в машинном обучении мы обсудили цели и задачи машинного обучения, и поговорили почему Cassandra — превосходный инструмент для обработки больших наборов данных. Также рассмотрели технологический стек, используемый Uber, Facebook и Netflix. Обе статьи основаны на воркшопе Machine Learning with Apache Cassandra and Apache Spark (Машинное обучение с помощью Apache Cassandra и Apache Spark).
В этой статье мы рассмотрим интеграцию Apache Spark с Cassandra и построение эффективных алгоритмов и решений. Мы также обсудим обучение с учителем, без учителя и метрики машинного обучения. Примеры и упражнения доступны на GitHub.
Базы данных (БД) существуют с первых дней программирования, а появились они ещё раньше. Это — неотъемлемые части любых приложений. Хорошо спроектированная БД — это один из важнейших компонентов, влияющих на производительность программных проектов. Из-за этого множество архитекторов программных решений исследовали массу подходов к управлению данными, пытаясь выяснить то, какие из этих подходов работоспособны в определённых сценариях, а какие — нет. Выбор подходящей архитектуры БД обычно сводится к выбору между SQL и NoSQL, между реляционными и нереляционными базами данных. А иногда в одном проекте используют и то, и другое.
В этой статье мы сделаем краткий обзор баз данных, поговорим об их истории, постараемся разобраться с тем, что собой представляют базы данных SQL и NoSQL, выясним ключевые различия между ними.
В этой статье сравним MongoDB и Cassandra — две самые популярные NoSQL базы данных.
На выбор подходящей СУБД для проекта может уйти довольно много времени. Требования к базе данных могут включать упрощенную модель данных, гарантию транзакций, производительность чтения/записи, горизонтальное масштабирование и отказоустойчивость.
Для начала нужно определиться с типом СУБД: SQL или NoSQL. Если вы выберите NoSQL, то дальше появляется вопрос: MongoDB или Cassandra. Да, на рынке существует множество NoSQL-баз данных, но среди них лидируют MongoDB и Apache Cassandra. Оба продукта похожи, но все-таки разные. Давайте сравним эти две СУБД, чтобы сделать правильный выбор.
Косметика в разделе с гаджетами, садовые лопаты в зоотоварах и непредсказуемо меняющиеся цены. Эти баги портили жизнь покупателям и сводили с ума разработчиков, ведь с ними ничего нельзя было поделать, но только до определенного момента.
Здравствуй, Хабр! Меня зовут Никита Вахрамеев, я работаю ведущим разработчиком в команде, которая занимается бэкендом витрины СберМегаМаркет. Основные направления нашей работы — листинги (каталоги товаров) и карточки товаров. В этом посте мы проведем небольшое расследование, погрузимся в нюансы шардирования и кэширования в ElasticSearch и исправим проблемы в каталоге на 16 миллионов товаров.
Внимание спойлер: индексы, во всем виноваты индексы!
Работа с геопространственными данными заведомо сложная задача, хотя бы потому что широта и долгота это числа с плавающей запятой и они должны быть очень высокоточными. К тому же, казалось бы, широта и долгота могут быть представлены в виде сетки, но на самом деле нет, не могут, просто потому что Земля не плоская, а математика - сложная наука.
Центр Развития Перспективных Технологий - компания разработчик системы мониторинга товаров. Как IT компания с большим количеством данных мы используем множество NoSQL решений в своей повседневной работе. Одним из таких решений является Apache Cassandra.
Суммарно, во всех кластерах Cassandra мы храним 0.4PB данных при общей емкости 0.9PB, стабильно производим 0.7млн операций записи и доступа к данным и 1.1млн когда необходимо разогнаться в трудные времена, при этом продолжаем непрерывно расширяться.
Отсюда лежит и название статьи, к моменту публикации последней главы из цикла петабайтный барьер емкости будет взят.
Материал подразумевает, что вы уже начали знакомиться с этой замечательной базой данных, хотите найти примеры её использования в российском сегменте интернета и будет полезен тем, кто постоянно ищет способ обучиться за счёт чужих ошибок. Ошибок мы совершили не мало, добро пожаловать!
Сердцем любого backend являются данные. Существует два сценария использования данных. В одном из них данные изменяются редко, но при этом активно используются в сыром или агрегированном виде и применяются для целей аналитики в реальном времени (такие системы принято называть OLAP). В других системах важно обеспечить сохранение с высокой скоростью большого количество неструктурированных или полуструктурированных объектов, поступающих от устройств Интернета вещей, из источников произвольных событий, наблюдений за активностью пользователя (такие системы называются OLTP - Online Transaction Processing, ориентированные на большое количество транзакций с минимальной задержкой обработки). Для таких систем важно обеспечить надежность хранения данных, поддержку распределенного хранения на нескольких серверах и/или дата-центрах и сохранение консистентности распределенного хранилища.
При этом сами объекты могут отличаться от привычной реляционной модели данных и представляться, например, в виде json-документов с произвольной схемой, объектов с полями со множественными значениями или графов. Разумеется это приводит к необходимости изучения новых подходов к поиску и добавлению данных, использованию специальных драйверов. Но что если соединить распределенное надежное хранилище и синтаксис запросов, близкий к SQL? В этой статье мы познакомимся с проектом Apache Cassandra и обсудим на примере разработки API на Kotlin для сбора телеметрии с датчиков, расположенных по всему миру (с поддержкой отказоустойчивости и управляемой репликации между дата-центрами).
Neo4j без преувеличения является самой распространенной графовой базой данных. Подход «schema free», гибкий язык запросов «cypher» — познакомиться с ней стоит хотя бы для расширения кругозора. Мы в компании Bimeister с целью повышения производительности провели серию экспериментов по переезду на Neo4j. Под катом я рассмотрю одну из сторон возможного апгрейда — импорт данных в графовую БД, проведу оценку ее преимуществ и недостатков и оценю время загрузки каждым из способов.
