ビッグデータ処理データベースの全体像と使い分け
2. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department自己紹介 {"ID" ："fetaro", "名前"："渡部 徹太郎", "所属"："リクルートテクノロジーズ ビッグデータ部" "研究"："東京工業大学で情報検索の研究（日本データベース学会）" "仕事"：{前職:["証券会社のWeb基盤", "オープンソース全般,主にMongoDB,NoSQL"], 現職:["リクルート横断のデータ分析基盤, "ExadataとHadoopの両刀使い"]} "エディタ"："emacs派" "趣味" ："自宅サーバ" "属性" : ["ギーク","スーツ"]} 1
Hadoopとリレーショナルデータベースは「何」が違うのか
書籍の中から有用な技術情報をピックアップして紹介する本シリーズ。今回は、秀和システム発行の書籍『Hadoopファーストガイド（2012年9月20日発行）』からの抜粋です。 ご注意：本稿は、著者及び出版社の許可を得て、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。 はじめに 近年、データサイズは増加傾向にあり、Webサイトを運営しているエンジニアやプログラマーにとって大規模データというのは身近なものになりつつあります。あなたの運営しているWebサイトではいかがでしょうか。たとえ今はリレーショナルデータベースで十分だとしても、今後も同じやり方で大丈夫だという保証はどこにもありません。 データサイズが増えてくると最初に問題となるのはバッチ処理です。データサイズが小さいうちは問題にならなくても、データサイズが増加してくると処理時
ØMQを使ってMicroservice間をロスレスでデータを同期させるStrongZero - Qiita
対象読者 2つの疎結合なシステム間を、メモリを大量に使っちゃうような大がかりな仕組みなしで、ほぼリアルタイムにデータロスなしに同期させたい、そういうアーキテクチャが欲しい方。 動機 Microservicesを疎結合に保ちつつ、バッチ処理やレポート機能でのクエリの高速化のため、データを同期させたいことがままあります。このあたりの話は、テキストの「5章 モノリスの分割」に載っています。 あるサービスから、データを定期的に吸い上げて、別のサービス、ツールに送るデータポンプという仕組みがあります。 イベント駆動でメッセージを関連サービスに送るイベントデータポンプや、バックアップツールを使って高速にデータ転送するバックアップデータポンプが紹介されていますが、結果整合性だけどなるべくリアルタイム(Near Real-Time)で同期させたいとなると、イベントデータポンプな仕組みしか選択肢にはならない
突然の大量データ分析奮闘記 - Qiita
この記事は CrowdWorks Advent Calendar 2017 20日目の記事です。 はじめに クラウドワークスでエンジニアをしている @yosu と @ToruIwashita です。 普段は主にCrowdWorksのアプリケーション基盤に関わる開発を行っています。 そんな中で最近、短期間で大量なデータを対象に複雑なデータ分析を行う必要がありました。 その際、普段のデータ分析では行わないような試行錯誤を経験したため、この記事ではそのとき起きたことを書いていきたいと思います。 背景 CrowdWorksではデータベースとしてMySQLを利用し、そのテーブル数は400超、総レコード数は数億あります。 このうち一部のデータはRedshiftに同期されていて、普段カジュアルにデータ分析したい場合はRedashを通してクエリを実行し、グラフ化、ダッシュボードの作成を行っています。 クラ
MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない - arclamp
「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。 Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品（OSS）があるだけです。 というわけで、「MSAに取り組む」というのは道は遠くても（見えなくても）「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる
大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント
バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービスのデータを管理する