distributed semi-structured search system
distributed semi-structured search system
MongoDBとは 10gen社が中心となって開発している非リレーショナルデータベース。 特徴 MongoDBは("humongous"より)は、スケーラブル、ハイパフォーマンス、オープンソース、スキーマフリー、ドキュメント指向です。C++で書かれていて、機能としては: ドキュメント指向ストレージ (the simplicity and power of JSON-like data schemas) 動的な クエリー 組み込みのオブジェクトと配列をサポートした完全な Index のサポート。 クエリー プロファイリング 速い in-place アップデート バイナリデータの効率的な保存 large objects (例:写真や動画) レプリケーション とフェイルオーバーのサポート。 クラウドレベルのスケーラビリティな 自動的なsharding 複雑な集約のための MapReduce 商用
AWS Week in Review – AWS Documentation Updates, Amazon EventBridge is Faster, and More – May 22, 2023 Here are your AWS updates from the previous 7 days. Last week I was in Turin, Italy for CloudConf, a conference I’ve had the pleasure to participate in for the last 10 years. AWS Hero Anahit Pogosova was also there sharing a few serverless tips in front of a full house. Here’s a picture I […] Amaz
KVS界隈ではすっかりおなじみ(?)のRedisですが、当社でも徐々にそのニーズが高まってきました。 標準機能として、レプリケーション、Pub/Sub、ソート等の便利機能が満載のRedisですが、サービスに投入する際に冗長構成をどう組むかといった点が気になっている方もいるのではないでしょうか。 まだまだ検証中ではあるのですが、Redisに実装されているRedisSentinelを用いて冗長構成を組んだ際にハマった所をご紹介したいと思います。 RedisSentinelとは Redisに標準実装されている機能の一つで、Redisのステータス監視、通知、自動フェイルオーバーが行なえます。 詳細な仕様、設定に関しては以下のドキュメントをご確認下さい。 http://redis.io/topics/sentinel RedisSentinel導入前の構成 特に何の変哲も無い構成です。 Redisサ
はじめに CX事業本部の佐藤智樹です。 今回はAWSが提供しているDynamoDB用のアプリ「NoSQL Workbench」の機能を使ってデータモデリングする流れを解説します。 最近案件でテーブル設計を再検討する必要がありNoSQL Workbenchを使ったところ、サンプルデータを入れながら設計が正しいか検証でき非常に便利だったので紹介します。 他の記事でもアプリの紹介はありますが本記事ではデータモデリングに絞って解説を行います。題材として多対多のデータをモデリングしながら設計する方法を紹介します。 本記事を読めば今までDynamoDBのデータ設計に悩んでいた方の検討時間をかなり減らすことができます。自分ももっと早く「NoSQL WorkbenchのData modeler はこう使って欲しい!」という記事があれば良かったなあと思ったので記事にしました。 NoSQL Workbench
補足説明: MySQLには、バージョン5.7から「JSONデータ型(JSON Data Type)」と呼ばれる概念が登場しています。これにより、JSON型を直接入れられるカラムを作成できます。 便利な一方、一般的なRDBの正規化を崩すことになりますので、仕様には注意が必要です。詳しくはこちらをご覧ください。 リンク WPJ もう知ってた? MySQL 5.7でNoSQLっぽくJSONデータを扱う方法 MySQL 5.7では、JSONデータを「JSON型」としてネイティブで扱えます。サンプルを見ながら、基本的な使い方を確認しましょう。 ※本記事は2016年5月31日に掲載した記事を一部再編集して更新したものです。執筆時点の技術情報をベースにしています。 「SQL vs NoSQL: The Differences」で紹介したように、SQLとNoSQLの境界線は、両言語が他方の特徴を取り入れる
大分たってしまったけど、ようやく時間が空いたので、db tech showcase Tokyo 2016 http://enterprisezine.jp/dbonline/detail/8466 で話した内容を記録的に書いておく。あとはSILOの解説を特に自分用に論文の4章を中心に整理しておく。あとはついでに自分の思うところも記す。 ・SILO 元論文はこちら、執筆陣はMITのLiskov一派とEddie Kohler 現在のDB研究の第一線のメンバー。 http://people.csail.mit.edu/stephentu/papers/silo.pdf SILO以降、大きくDBベースのアーキテクチャの考え方は変わりました。ほとんど全ての分散系OLTPはSILOを程度の大小はあるとはいえ、意識していると言っても過言ではないでしょう。前世代ではほぼ「空想か?」ぐらいの扱いだった分散t
クリティカルスピードは〜のオープンソース・ソフトウェア。高速なレスポンスを行うWebサーバは誰しもが願う所だ。Googleがあれだけ大きく成長したのは検索のアルゴリズムはもちろんのこと、高速なレスポンスにも一因があったと思われる。欲しい情報がすぐに手に入るというのはとても気分がいい。 表示が速い! Webサーバで高速化を行うための手法は幾つか存在する。並列化したり、サーバのスペックを上げたり、ネットワークを強化すると言った方法の他、システム側でも対応できるものがある。その一つ、高速配信サーバのクリティカルスピードを紹介しよう。 クリティカルスピードの最大の特徴はKVS(キー・バリュー・ストア)をWebサーバとして使っていることだ。KVSとしてTokyoTyrantを採用しているが、今後はLuxIO、kumofs、ROMAといった他のKVSにも対応していくとのこと。WebサーバはPlack/
Firebase Realtime DBを実践に投入する Databaseと聞くと、これから利用しようとするFirebaseがmBaaSであることを忘れてついREST(Client Server Model)で考えてしまいがちですが、大前提はMobile Platformなので、一度REST、RDBの考え方は捨ててみてください。 RDBの考え方を引き継いだままでは、Firebase Realtime DBの最善の設計はできないと考えています。 そして、RDBの考え方を引き継いだままFirebase Realtime DBを理解しようとすることが、導入の一つの障壁となっていると思っています。 ぜひ頭をリフレッシュしてFirebase Realtime DBの見方を変えてみてください。 この記事では、Firebase Realtime DBの導入するにあたっての考え方やテクニックを紹介します。
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”(granularity)がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
Let's face it, writing MongoDB validation, casting and business logic boilerplate is a drag. That's why we wrote Mongoose. const mongoose = require('mongoose'); mongoose.connect('mongodb://127.0.0.1:27017/test'); const Cat = mongoose.model('Cat', { name: String }); const kitty = new Cat({ name: 'Zildjian' }); kitty.save().then(() => console.log('meow')); Mongoose provides a straight-forward, schem
ログは、システムの障害解析(デバッグ)や運用モニタリングに使うことを想定して、コンピュータに発生したイベントの履歴を時系列に沿ってファイルに出力したものである。有用なデータではあるが、扱いにくい面がある。そのため、複数のログを突き合わせて分析するといった活用が難しく、従来はもっぱら一つのログを単独で利用するにとどまるケースが多かった。 扱いにくい面とは、例えば「ログを一括して処理するには対象ログを各サーバーから収集しなければならない」「ログはサイズが大きくなりがちなので収集する場合は一部を抜き出すなどの加工が必要」といったことである。ログに新たなデータが書き込まれた際に、それを即座に取り出す手段が用意されていないこともそうだ。 こうしたログの扱いにくさは、「ログ収集基盤」と呼ばれるソフトウエアを使うことで克服可能である。ログ収集基盤は、複数のログを結び付けて分析する際などに必要な、対象ログ
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました! スティッキーセッション ロードバ
と名だたるIT企業が立て続けにRDBMS製品をリリースし、この時期にリリースされた上記のDBによって現在のRDBMSシェアは9割を超えると言われています。 このように、多数のデータベース製品がリリースされた背景には、1970年~1990年頃においてビジネスフィールドへのITシステム導入が急速に進んだことがありました。 この時代ではまだ世の中はパソコン/インターネット時代には到達していないため、この時代のITの中心は正にこうしたデータベースによる情報管理そのものにあったと言っても過言ではありませんでした。 広義のDBMS(データベース管理システム)としてはリレーショナル型の他にネットワーク型、カード型、階層型などがありますがビジネスモデル(トランザクションの必要性など)に最もよく合致したのがRDBMSでした。RDBMSにおける"リレーショナル"とは 個々のデータ(レコード)がいくつか属性(カ
※分散Key-Valueストア「kumofs」を公開しました! 先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。 kvs-kumofs.pdf 合わせて読むと理解が深まるかもしれない: スマートな分散で快適キャッシュライフ - mixi Engineer's Blog:Consistent Hashについて バイナリシリアライズ形式「MessagePack」:kumofsのプロトコル。高速なストリームバッファとストリームデシリアライザの実装も含まれています。 Protocol Buffersは遅い:MessagePackのベンチマークとProtocol Buffersとの比較。タイトルは釣り。 memstored:IOアーキテクチャのプロトタイピング マルチコア時代の高並列性IOアーキテクチャ Wavy memcached
はじめに 2010年のはじめ、TwitterがApache CassandraというJavaで実装された分散型のデータストアシステムを採用しつつあるというニュースが話題を呼びました。このことでCassandraは、NoSQLと呼ばれるシステムの中で最も注目を集めるものの一つになったと言えるでしょう。 2010年7月の時点で、Twitterは、位置情報のデータストレージ、トップツイート(トップページに表示される人気ツイート一覧)などのリアルタイム分析、データマイニング処理など、多くの用途でCassandraを活用しています。また、Cassandraを生み出し、のちにApache Foundationに寄贈したFacebookでは、5億人規模・150Tバイト以上のデータ量を持つユーザメッセージの検索機能(Inbox Search)を、150ノードのCassandraクラスタで処理しています。
はじめに WAF「Scutum(スキュータム)」ではサービス開始時より、データストアとしてmemcachedとpgpool II+PostgreSQLを利用しています。これらはどれも安定して動いており満足しているのですが、最近になってより柔軟にデータを取っていきたいというニーズが高くなってきたため、MongoDBの導入を行いました。まだ完全なリプレースまでは至っていませんが、元々のデータベースのスキーマ構造がシンプルであることもあり、数ヶ月以内にはpgpool II+PostgreSQLの部分をMongoDB(Replica Sets)で置き換えることができるのではないかと思っています。 MongoDBにとっての「メモリ使用量」 MongoDBを導入するにあたり、Linux(X86_64)上でMongoDBを動作させたときのメモリの消費について、簡単にですが調べてみました。まず参考にしたの
米オラクルはエンタープライズ向けNoSQLデータベース「Oracle NoSQL Database 11g」の公開を発表。評価版の無償ダウンロードを開始しました。オープンソースライセンスに基づくコミュニティ版も準備中(10月26日現在、ライセンス承認待ち)とのことです。 Oracle NoSQL Databaseは、同社のキーバリューストアであるOracle Berkeley DB Java Editionをベースに、分散処理機能、ロードバランス、管理機能、マルチノードバックアップ機能などを追加したもの。大規模なデータを高速に扱うことができ、高い可用性とスケーラビリティを実現すると説明されています。 分散キーバリューストアで単一障害点を排除 NoSQL Databaseの基本的なアーキテクチャは、プライマリキーのハッシュによって指定されたノードにキー/バリューのペアを書き込む分散キーバリュ
Lux IO is a yet another fast database manager. It supports B+-tree and Array index in either cluster or non-cluster index. It's originally designed for storing large expanding data as a value in Lux Search Engine, but it's also pretty fast for small and a large number of data. Fast key lookup (B+-tree, Array) Support both clustered and non-clustered index mmap(2) the whole index structure in clust
こんにちは。最近はAndroidアプリ開発に入門しました、@edvakfです。 pixivではキャッシュ兼汎用KVSとしてKyotoTycoon (KT)を使用しており、頻繁にアクセスされるキーはアプリケーションサーバー内のAPC(PHPのshared memory cacheです)にもキャッシュすることで多段化しています。 このような構成の弱点として、「ほとんどの場合は値が無いけど毎回存在確認が必要なキー」の場合に前段にキャッシュが無くて毎回後段にまで問い合わせなければいけないという問題があります。ネガティブキャッシュ(値がないことをキャッシュする)を使うという手もありますが、問い合わせるキーの数が膨大になってくると現実的ではありません。 pixivでは、作品に付いている最大10個のタグについて、ピクシブ百科事典に記事があるかどうかを判定する必要がありました。これに加え、最近ではBOOT
先日、Brian Akerとミクシィの前坂氏によるmemcachedのセミナーがあった。 実践で使用する上での話や開発最前線の話が聴けたため、セミナーは非常に盛況であった。筆者にとっても非常に勉強になる内容だった。セミナーの資料はBrian Aker氏のサイトから入手できるのでセミナーに参加出来なかったひとはこの資料を読んで自習して頂きたい。 が、いかんせん氏のスライドはパッと見ただけではなんとなく分かりづらいように俺は思う。なぜだろうか?それはきっと図がないからだ・・・と勝手に想像する。オトコたるもの、時には勝手な憶測で突き進むのもアリだ。ちなみにBrianのスライドはほとんど要点の箇条書きになっている。これでは解説がないと、特に新規にmemcachedやMySQLを学習している人たちには分かりづらいだろう。 というわけで氏に代わり、memcachedがどのように既存の仕組みを置き換える
Sematextのブログにて連載された"Solr vs ElasticSearch"の翻訳。 現在、Part 6まで存在し、その全てを翻訳した。 Part 1 – 概観 Part 2 – インデックス作成と言語の取扱 Part 3 – 検索 Part 4 – Faceting Part 5 - 管理APIの機能 Part 6 – ユーザと開発者のコミュニティ比較 なお、オリジナルの記事はこちらのPart1から全て辿ることができる。 http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ この連載はまだ続くはずだがPart 7がいつ出るのかはわからない。また出た時に翻訳を続けられるかもわからない。 なお、訳者はSolrもElasticSearchも大した知識を持っていない。誤訳等見つけられたらぜひコ
C#の非同期構文をフル活用し業界最速の応答速度を実現 現在、多くのソーシャルゲームがPHPやPython、Rubyといった、いわゆるLightweight Languageを使って開発されていますが、(株)グラニではプログラミング言語としてC#を採用し、Windows環境で開発および運用を行っています。実は、現在提供している「神獄のヴァルハラゲート」は、2013年1月のリリース時点ではPHPを利用していました。しかし同年4月にC#への移植を開始し、3ヵ月後の7月16日にはC#への切り替えを完了させています。 このようにC#にこだわっている理由の一つがパフォーマンスです。ソーシャルゲームはユーザがアクションを起こすたびにデータが更新されるというしくみ上、どうしてもViewのキャッシュを効かせられなかったり、1万リクエスト/秒を超えるような高負荷が発生したりしますが、そうした状況においても平
Overview Kyoto Tycoon is a lightweight database server with auto expiration mechanism, which is useful to handle cache data and persistent data of various applications. Kyoto Tycoon is also a package of network interface to the DBM called Kyoto Cabinet. Though the DBM has high performance and high concurrency, you might bother in case that multiple processes share the same database, or remote proc
前回はCassandraとは何かを簡単に説明しました。第2回では、Cassandraを実際にインストールして開発環境で動かしてみましょう。 Cassandraをインストールしよう 環境を確認する まずは環境の確認をしましょう。筆者の環境は以下のようになっています。 Windows 7 Professional Sun JDK 1.6.0_18 64bit Eclipse 3.5.1 この連載ではおもにWindowsでの環境を想定しています。ただ、CassandraはJavaベースなので、MacやLinuxなど別OSでも同様に動くはずです。 Cassandraをダウンロードする 本連載では現時点での最新版Cassandraha 0.6.1を使います。以下のサイトからダウンロードできます。 The Apache Cassandra Project URL:http://cassandra.ap
ハンガリーの企業でCTOを務めるKristof Kovacs氏による記事です。各主要NoSQLプロダクトについて機能比較や利用ケースなどをまとめています。この記事ではCassandraやRedisなど6つのプロダクトを挙げています(表1)。 CouchDBは使い勝手に優れており、双方向レプリケーションやリアルタイム更新をサポートしています。Redisは非常に高速なことが売りで、トランザクションや変更監視の機能が備わっています。Cassandraは書き込みが読み込みよりも速いことから銀行や金融などのリアルタイムなデータ解析が必要になる分野で実力を発揮し、Cassandraと同じくJavaで作られているHBaseは億単位の行と数百万のカラムというBig Dataを扱え、月に1,000億を超えるメッセージを処理するFacebookのバックエンドに採用されています。 次々にプロダクトが生まれた
カテゴリー DX (2) 一般 (59) 研究会 (6) 働き方 (4) 技術 (352) Edge AI (2) Edge Computing (13) Erlang (1) FIWARE (2) Fog Computing (10) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (5) RealTime Web (14) SRE (3) Webサービス (42) インフラ (8) コンテナ (4) ストレージ (93) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (215) 仮想化 (111) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティン
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! 山下郁矢です。2018年新卒で入社し、現在はNoSQLデータベースエンジニアとして働いています。 サービスを作るにあたってデータベースは必要不可欠ですよね。ヤフーでは100を超えるサービスで毎日生み出される膨大なデータを、データベースを用いてリアルタイムで蓄積し、運用管理しています。 今回は、その中でも利用規模の大きい、NoSQLデータベースの1つであるApache Cassandraを皆様に知ってもらうべく、ヤフーでどのようにして利用されているのかをお伝えしたいと思います。 NoSQLの立ち位置 Cassandraについてご紹介する前に、NoSQLについて軽く説明します。 NoSQLデータベースは一般的に非RDBM
原文(投稿日:2011/11/07)へのリンク 最近、MongoDB に関して非常に好ましくない内容のかなり話題になった市場報告が2つあった。批判の大部分は、パフォーマンス問題とデータ損失の組合せに集中している。この話を続ける前に、これらは公式の事例研究でないことを肝に命じて欲しい。そうではなくて、最近 MongoDBを使った開発チームによる市場報告である。 まず Urban Airshipの Michael Schurter氏のレポートから始める。 Urban Airshipは既に、MongoDBの問題を経験しており、このレポートを書く前にデータのほとんどを PostgreSQLに移行を済ませていた。残ったデータはMongoDBにとって理想的のようだ。 短命-もしそれを失っても、短い間サービス低下を経験するが、 壊滅的ではない 小さい-容易にメモリーに収まる(~15 GB) 二次索引-キ
グーグルでMySQLエンジニアリングチームを率いたのち、現在はFacebookに在籍しているMark Callaghan氏がブログ「High Availability MySQL」にポストしたエントリが発端になって、MySQL+Memcachedの時代は過ぎたのか? という議論が巻き起こっています。 元グーグルMySQL担当エンジニアが弱気な発言? Callaghan氏がポストしたエントリ「Plays well with others」は次のような一文で始まり、MySQLについてややシニカルに書かれているように読めます。 A few years ago MySQL+memcached and PostgreSQL+memcached were the only choices for high-scale applications. That has changed with the ar
Voldemort is a distributed key-value storage system Data is automatically replicated over multiple servers. Data is automatically partitioned so each server contains only a subset of the total data Server failure is handled transparently Pluggable serialization is supported to allow rich keys and values including lists and tuples with named fields, as well as to integrate with common serialization
Cloud Foundryで始めるPaaS構築入門:CloudFoundryで始めるPaaS構築入門(1)(1/2 ページ) この連載では3回に分けて、「Cloud Foundry」というオープンソースパッケージを用いて、Platform as a Service(PaaS)のためのインフラストラクチャを構築する方法について解説します。 Platform as a Serviceとは何か クラウドコンピューティングに対する注目が高まる中、Platform as a Service(PaaS)という言葉をすでにご存じの方も多いことでしょう。これは、元々セールスフォース・ドットコムが2007年に打ち出したコンセプトです(用語説明)。 PaaSのサービスプロバイダは、ユーザーに対して、アプリケーションサーバ、データベースサーバなどの「プラットフォーム」環境を提供します。PaaSのユーザーはこれら
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く