データダッシュボードのスタートアップCountが約2.6億円を調達

アーリーステージの企業は、組織全体で扱うデータ量に悩まされることが多い。データが増えてくると、特にそうだ。データソフトウェア、データの混乱、データパイプラインの扱いに多額の費用がかかる。これらはすべてデータウェアハウス、クリーニングツール、視覚化プラットフォームに関わる。

Countは、オールインワンのデータプラットフォームを作ってこの問題を解決しようとしているスタートアップで、アーリーステージのチームに安価なデータパイプライン構築のためのツールを提供している。

Countはこれまでのステルスモードを終了し、240万ドル(約2億5800万円)の資金調達を発表した。この資金調達はLocalGlobeが主導し、Global Founders Capitalが参加した。同社のエンジェル投資家には、Micrrosoft(マイクロソフト)の企業戦略責任者だったCharlie Songhurst(チャーリー・ソンハースト)氏がいる。

Countは2016年に、経営コンサルタントだったOliver Hughes(オリバー・ヒューズ)氏とインペリアルカレッジの物理学者のOliver Pike(オリバー・パイク)氏が創業した。2人は、標準的なデータソフトウェアの複雑さと、業界で容認されている技術や設計上の制限のため、企業はデータドリブンの決定を下すことができないと分析していた。

発表の中でヒューズ氏は、同社が解決しようとしている問題について次のように述べている。「大きく成長しているチームは、データを管理するために複数の別々のソリューションに対して多額の投資が必要だった。そのようなソリューションを購入して実装するには1年から1年半かかる。そのため多くのスタートアップは、ツールが自分たちに合わなくなっても長期の契約に縛られる。Countはシンプルな従量課金制モデルなので、プラットフォームを無料で使い始め、チームの成長とデータの増加に伴ってその分だけ支払えばよい」。

LocalGlobeのパートナー、Remus Brett(レマス・ブレット)氏は次のように述べている。「データが極めて重要であることは多くの人が認識しているが、データを扱い、ストーリーを語るのはいまだに難しい。現在では、重要な決定をするためにデータを迅速に処理し分析することの価値は、かつてないほど大きい。Countを利用すれば、ごく初期の企業であってもデータ分析に基づいた意思決定を始められる」。

Countを利用しているTiney.coのCTO、Edd Read(エド・リード)氏は「Countによって我々はデータをすべてまとめてチーム全体の報告書を作れるようになった。同社の製品であるNotebooksを使えば、状況に応じた考察を共有し、SQLを学ばなくてもデータのクエリを利用できる」と述べている。

Countには、データウェアハウスではSnowflake、データクリーニングツールではDBT、分析プラットフォームではLookerなど、多くの競合がある。

[原文へ]

(翻訳:Kaori Koyama)

Google CloudでMemcachedが使えるようになった

GoogleはこのほどMemorystore for Memcachedのベータ版を公開した。GoogleのMemorystoreサービスは高速性が必要とされる大規模データベースなどをクラウドのインメモリで作動させるのに適しているが、ここでMemcachedがフルマネージドで利用できるようになった。これは複数サーバのメモリを統合して利用するためのオープンソースのプロトコルで、2018年にGoogleがスタートさせたRedis向けインメモリデータストアサービスに含まれることになる。

米国時間4月3日の発表でMemorystoreのプロダクトマネージャー、Gopal Ashok(ゴパル・アショク)氏は「Redisは今後もセッションストア、ゲームのリーダーボード、ストリーミング分析、マルウェアの脅威検出、APIレート制限などのユースケースで引き続き人気ある選択肢だろう。現在、Memcachedはデータベースのキャッシュのレイヤーとして頻繁に利用されている。デベロッパーはMemcachedをセッションストアにもよく用いている。我々の新サービスを利用すれば、インスタンスごとにメモリのクラスターのサイズを最大を5TBまで拡張できる」と述べている。

このサービスは名称のとおり、オープンソースのMemcachedと完全に互換性がある。従ってデベロッパーはコードに手を加えることなくMemcachedプロトコルを利用した既存のアプリケーションをGoogle CloudのMemechacedプラットフォームで運用することができる。

フルマネージドサービスなので作動のモニタ、パッチの適用などの定型業務はすべてGoogleが処理する。最大キャッシュサイズを決める部分にはやや職人技が残るが、Google Cloudでは「詳細な統計を提供するのでデベロッパーはインスタンスの大きさを上下させ、実行するユースケースに対して最適なキャッシュサイズを容易に設定できる」としている。Googleが提供するモニタ情報は Cloud Monitoringによって測定される。これはGoogle Cloudの中心的ダッシュボードであると同時にAWSの動作も計測できるという。

現在、Memorystore for Memcachedは Compute Engine、Google Kubernetes Engine(GKE)、App Engine Flex、App Engine Standard、Cloud Functionsで実行されるアプリケーションに使用できる。

Memcachedの利用に関しては、AWSがElastiCache for Memcachedで同種のサービスを提供している。またMemCachierなどこのプラットフォームの利用を専門とするスタートアップがある。Redis Labsも、フルマネージドのMemcachedサービス、Memcached Cloudを提供している。このサービスはAWS、Azure、Google Cloudで実行できる。

画像クレジット:Krisztian Bocsi/Bloomberg/Getty Images(Googleのベルリンオフィス)

原文へ

(翻訳:滑川海彦@Facebook

DigitalOceanがPostgreSQLに続いてMySQLとRedisのマネージドデータベースサービスをローンチ

半年前にPostgreSQLのマネージドサービスをローンチしたばかりの、新進のホスティングおよびクラウドサービスプラットホームDigitalOceanは米国時間8月20日、MySQLとRedisのマネージドデータベースサービスのローンチを発表した

これも含め同社の最近のリリースは、低価格なホスティングサービスというルーツを脱して本格的なクラウドプロバイダーになろうとするDigitalOceanの意欲の表れだ。データベースのマネージドサービスと同社のコアであるホスティングおよびインフラストラクチャに加えて、今や同社はオブジェクトとブロック単位のストレージとKubernetesエンジンも提供しており、とくに後者は今日の現代的なクラウドインフラストラクチャならどれの上でも利用ができ、動かせる。ハイパークラウドと呼ばれる連中に追いつくのはまだかなり先だと思われるが、市場の競争がより激しくなるのは良いことだ。

DigitalOceanのプロダクト担当上級副社長Shiven Ramji(シヴァン・ラムジ)氏は、次のように述べている。「MySQLとRedisを加えたことによって、DigitalOceanは今やもっとも要望の多い3つのデータベースをサポートしている。しかもデベロッパーは、それらの面倒な管理で悩むことなく、アプリケーションを構築し動かすことができる。デベロッパーはDigitalOceanのDNAであるだけでなく、その成功の大きな要因でもある。私たちはこの成功を足がかりとしてさらにデベロッパーのサポートを拡充し、彼らのよりシンプルなアプリケーション開発を可能にしていかなければならない」。

マネージドデータベースサービスの料金体系は、どれを選んでも前と同じだ。

2019 08 19 1553

新しいマネージドデータベースサービスは当面、同社のニューヨークとフランクフルト、サンフランシスコのデータセンターで提供される。そのほかのデータベースエンジンのサポートも、目下開発中だ。2番目3番目としてMySQLとRedisを選んだのはデベロッパーの要望が多いからだが、そのほかのエンジンについても、同じくデベロッパーの要望の多さが選択のベースになるだろう。ただしDigitalOceanの2019年のロードマップに載っているデータベースはMySQLとRedisだけだから、年内に次のサポートが発表されることはないだろう。

関連記事:DigitalOcean launches its managed database service(DigitalOceanがマネージドデータベースサービスをローンチ、未訳)

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

MicrosoftがPostgreSQLデータベースを加速するCitus Dataを買収、顧客をAzure化か

Microsoftが今日(米国時間1/24)、Citus Data買収したことを発表した。Citus Dataは、PostgreSQLデータベースのスピードとスケーラビリティの向上をサービスとして提供している。同社のPostgreSQLエクステンションはオープンソースのプロダクトで、PostgreSQLデータベースを分散データベースに変換する。NoSQLやドキュメントストアが騒がれている今日でも、リレーショナルデータベース、とくにPostgreSQLは今だに成長市場であり、その理由の一部は、Citusのような企業が、その限界を克服するツールを提供しているからだ。

当然ながらMicrosoftのねらいは、Citus Dataのチームとの協働により“Azureの重要なエンタープライズ機能のPostgreSQLへのデリバリを加速し、重要なPostgreSQLワークロードが確実にAzure上で動くようにする”ことだ〔PostgreSQLユーザーのAzure化〕。Citusの協同ファウンダーたちも、彼らの声明文で同じようなことを言っている: “Microsoftの一員としてわれわれはこれからもPostgreSQLをベースとする素晴らしいデータベースの構築に力を入れ、ユーザーに画期的なスケーラビリティとパフォーマンスおよび彼らが必要とする障害時自己回復力を提供していく。われわれは、この分野におけるイノベーションの推進を継続する”。

PostgreSQLは言うまでもなくオープンソースのツールで、そしてMicrosoftも今やオープンソースの主要なコントリビューターであることは周知の事実だから当然かもしれないが、同社はPostgreSQLのコミュニティとの協働も強調している。Microsoftのスポークスパーソンの言い方では、“この買収は弊社のオープンソースへのコミットメントの証(あかし)であり、Azure PostgreSQLのパフォーマンスとスケーラビリティの向上が目的である”、となる。

Citusの現在の顧客は、リアルタイムアナリティクスのChartbeatや、メールのセキュリティサービスAgari、そしてPushOwlなどだ。名前は挙げないが、Fortune 100社企業も多いという。同社はクラウドからのDBaaS(database as a service)とオンプレミスのエンタープライズバージョンの両方を提供している。そして無料のオープンソースエディションもある。今後も当分それは変らないが、Microsoftは徐々に、CitusがホストしているサービスをAzureへ移行させていくのではないか。

買収の価額は公表されていない。2010年に創業したCitus DataはY Combinatorのインキュベータ事業を卒業し、これまでKhosla Ventures、SV Angel、Data Collectiveなどから1300万ドルを調達している。

関連記事: CitusDBがPostgreSQL用の列取り出しツールをオープンソースで提供開始, 複雑なクェリの効率をアップ

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

MongoDBがそのコードのオープンソースライセンスを改定、オープンソースの“食い逃げ”に むかつく

MongoDBは一部の、とりわけアジアの、クラウドプロバイダーのやり方にムカついている。彼らはそのオープンソースのコードを利用して、同社のデータベースの商用バージョンを、オープンソースのルールを無視してユーザーにホストしている。これと戦うためにMongoDBは今日(米国時間10/16)、Server Side Public License(SSPL)と名付けた新しいソフトウェアライセンスを発行した。それは同社のMongoDB Community Serverのすべての新しリリースに適用され、前のバージョンの新しいパッチに対しても適用される。

これまでMongoDBはGNU AGPLv3ライセンスを使ってきたが、今度はSSPLをOpen Source Initiativeに申請して承認を待っている。

現在コミュニティサーバーを使っている通常のユーザーは全員、新しいライセンスが適用されないので何も変らない。むしろこれは、MongoDBがAGPLv3ライセンスの誤用とみなしているものへの対策だ。MongoDBはこう説明している: “MongoDBはこれまで、GNU AGPLv3でライセンスされていた。したがってMongoDBを一般公開サービスとして動かしたい企業は、自分たちのソフトウェアをオープンソースにするか、またはMongoDBから商用ライセンスを入手しなければならない。しかしながらMongoDBの人気のゆえに、一部の企業はGNU AGPLv3の許容限界を試そうとしている”。

つまり、SSPLはGNU GPLv3とそれほど異なるライセンスではない。GPLとほぼ同じ言葉で、コードの利用、変更、再配布の自由が明記され、しかしSSPLが明示的に声明しているのは、MongoDB(やSSPL下のそのほかのソフトウェア)をサービスとして提供しようとする者は何人(なんぴと)たりとも、商用ライセンスを得るか、またはサービスをオープンソースにしてコミュニティに還元しなければならない、という点だ。

MongoDBのCTOで協同ファウンダーのEliot Horowitzは、声明の中でこう述べている: “市場はますます、ソフトウェアをサービスとして消費しており、そこに、オープンソースの優れたサーバーサイドソフトウェアのニューウェーブが生まれ育つすばらしい機会が作られている。しかし残念ながら、一度オープンソースプロジェクトの味をしめたクラウドベンダーはあまりにも安易に、それが自分が開発したソフトウェアではないにもかかわらず、その価値のすべてを取り込み、コミュニティに何も寄与貢献しなくなっている。われわれはオープンソースに大きく貢献し、大きな恩恵を受けている。そういう企業としてわれわれは、多くの企業に影響を及ぼす問題で先頭に立つべき、独自の立ち位置にある。これが今後さらに多くのプロジェクトを刺激して、オープンソースのイノベーションが守られることを望みたい”。

この動きが、一部の人びとの反感を招くことも確実だ。オープンソースのライセンスについて語るときには、その運動の本質をめぐって宗教的な口調にどうしてもなりがちだ。そしてMongoDBはそのソフトウェアの背後にいる商業的実体であり、コードへの外部からのコントリビューションを管理しているから、たとえば大きなオープンソースのファウンデーションなどが管理するプロジェクトと違って、コードに対する一社の権限や態度が実質的にきわめて強い。だからMongoDBがオープンソースの何たるべきかを語るのはお門違い、と見るむきもある。オープンソースはソフトウェアを開発するための実用的な方法にすぎない、という考えもある。

しかしいずれにしてもこれは、私企業とその企業のオープンソースプロジェクトの管理との関係はどうあるべきかをめぐる議論の、契機になると思われる。自分のコードの使われ方に関して、MongoDBのような企業は、どれだけのコントロールを及ぼしうるのか? 今日のHacker Newsを読むのが、楽しみだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Facebookが世界各地に分散したデータセンターのログを保存するツールLogDeviceをオープンソース化

Facebookは、複数箇所に分散しているデータセンターのログを保存するための自家製のソリューションLogDeviceを、オープンソースにすることを計画している。その発表は、同社のScaleカンファレンスで行われた。

それらのログは、データベースのイベントを調べるために利用されている。何かの理由でサーバーがダウンしたときには、デバッグする方法が必要だし、セキュリティのための監査を行って、サーバー間の整合性を確保しなければならない。大量のユーザーデータが世界中の大きなデータセンターに分散しているFacebookでは、このことがとくに重要だ。

LogDeviceは、ハードウェアやネットワークに問題があってもデータを記録できる。何かの不具合が生じたらログ収集のタスクを他のデータセンターにお願いする。そして回復したら、問題のあったデータセンターのレコードを毎秒5〜10ギガバイトのスピードでリストアする。

Facebookのデータセンターはもうすぐ10箇所になるが、各センターのレコードは確実に同じページに載ってほしい。しかしそこには、バックアップという複雑な問題があるので、データの扱いは一層難しくなる。LogDeviceは、これらの、各所に分散したデータセンターのデータを複製する作業を支援する〔上記のような場合も含め〕。

高価なサーバーをどうしても故障引退させなければならないときでも、LogDeviceは失われたレコードを正しく教えてくれる。レコードのシーケンスとサーバーのストレージを最初から分離し、レコードをさまざまな場所のストレージにランダムに割り当てるので、データセンター全体の自己回復力が強化される。

LogDeviceをいつからオープンソースにするのか、そのスケジュールは公表されていないが、今年のおそい時期に、とは言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

SalesforceがAIを利用して自然言語の質問をSQLに翻訳、事務系社員でもデータベースを利用できる

SQLはプログラミングの世界ではやさしい方だが、ふつうの人たちがリレーショナル・データベースを対話的に利用したいと思ったときには、やはりその学習曲線は急峻だ。そこでSalesforceのAIチームは、SQLを駆使できない人でもデータベースを使えるために、機械学習を利用できないか、と考えた。

彼らの最近のペーパーSeq2SQL: Generating Structured Queries from Natural Language using Reinforcement Learning(強化学習を使って自然言語からSQLを生成する)は、機械学習でよく使われるシーケンス変換モデルを利用している。強化学習の要素を加えたことによりチームは、自然言語によるデータベースへのクェリをSQLに翻訳するという課題に対し、かなり有望と思われる結果を得た。

すなわちミシガン大学のデータベースに対し、データベースにフットボールの優勝チームを尋ねるクェリで、正しい結果が得られた。

このプロジェクトに関わった研究員の一人、SalesforceのVictor Zhongは、こう語った: “クェリの正しい書き方は一つではない。自然言語で言われた質問*に対し、それを表すSQLのクェリは二つも三つもあるだろう。われわれは強化学習を利用して、同じ結果が得られるクェリを使うよう、学習を誘導した”。〔*: 自然言語は、語形はまったく同じでも、話者の込めた含意がさまざまに異なることが多い。〕

どなたもご想像できると思うが、ボキャブラリーがとても大きいと、機械翻訳という問題はたちまち複雑困難になる。しかし、翻訳の可能性の多様性を野放しにせずに、どの語に関しても少数に限定してやると、問題はよりシンプルになる。そのためにSalesforceにチームは、ボキャブラリーを、データベースのラベルに実際に使われている語に限定した。つまりそれらの語は、SQLのクェリに実際に登場する語だ。

SQLの民主化は、これまでにもいろいろ試みられている。たとえば最近Tableauに買収されたClearGraphは、データをSQLでなく英語で調べることを、自分たちのビジネスにしている。

“データベース本体の上で実行されるようなモデルもある”、とZhongは付言する。“しかし、社会保障番号を調べるような場合は、プライバシーの懸念が生じる”。

ペーパー以外でSalesforceの最大の貢献は、モデルの構築に利用したデータセットWikiSQLだ。最初に、HTMLのテーブルをWikipediaから集める。これらのテーブルが、ランダムに生成されるSQLクェリのベースになる。これらのクェリを使って質問を形成するが、それらの質問はAmazon Mechanical Turkで人間に渡されてパラフレーズ(語形変化)される。それぞれのパラフレーズは二度検査され、人間によるガイダンスが付く。そうやって得られたデータセットは、このようなデータセットとしてはこれまでで最大のものだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Facebookがデータセンター内ネットワークを新型スイッチとともに40GBから100GBにアップグレード中

front_full-loaded

Facebookは今、同社のデータセンター内の光ファイバーネットワークを40GBから100GBにアップグレードしようとしている。同社のトップ・オブ・ラック・スイッチ(ひとつのラック上のすべてのサーバーを接続するスイッチ)Wedge 100は今日(米国時間11/8)すでにOpen Compute Projectに受諾され、またすべてのラックをデータセンター内で接続する次世代100GスイッチプラットホームBackpackもベールを脱いだ。

FacebookのDirector of Software Engineering for NetworkingであるOmar Baldonadoによると、同社がこの、より高速なネットワーキング技術を必要とする理由はいくつかある。しかしその最大の要因は、ライブと録画双方のビデオのサポートを拡大することだ。さらに、360度の写真やビデオも含まれる。Facebook自身の内部的なデータセンタートラフィックも、ユーザー体験の改善のために、アナリティクスなどのデータへの需要がデベロッパー部門から増えており、それにも対応しなければならない。

しかし100Gは、今でもまだ、高速ネットワーキングの最先端技術だ。もちろん今それに取り組んでいるのはFacebookだけではない。たとえばLinkedInも最近、オレゴン州のデータセンターを将来100Gにする計画を発表した。Facebookが他と違うのは、サーバーの設計やネットワーキング技術、およびそれらを支えるソフトウェアを、業界全体のためにオープンにすることに、コミットしていることだ。

  1. iso_front_1.jpg

  2. iso_back_1.jpg

Baldonadoによると、40Gから100Gへの移行で生ずる問題の一つが、新しいデバイスの“電力大喰らい”癖、そして冷却の困難さだ(彼は、“ゲーム用PCをオーバークロックでずっと使うようなもの”、と言った)。“それだけのハイスピードはどうしても必要だけど、そのためにはスイッチだけでなく、データセンター全体としての対応が必要になる”、と彼は語る。“だから業界のあらゆる部分…サーバーのベンダ、NICのメーカー、光りファイバーのメーカー、などなど…と協働しなくては、これだけのスケールアップは実現できない”。

Backpackの能力が前の“6-pack”スイッチの2.5倍だとしても、その電力消費量も2.5倍なのだ。

Facebookは、BackpackスイッチもOpen Compute Pojectに出す予定だ。それは今、社内テストの段階から徐々に、同社のデータセンターに実装されつつある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Bashoが時系列データ専用NoSQLデータベースRiak TSをオープンソース化してIoTへの浸透をねらう

internetofthings

世界中のありとあらゆるデバイスメーカーが、自分たちの製品をインターネットに接続しようとしているように、思える。ベッド用のマットレスも、洗濯機も、トースターも、そしてジューサーも〔冷蔵庫も〕。大量のデータが空中や線上にあふれ出て、分析されるのを待つ列に並ぶだろう。

そのようなデータは今後増加の一方で、それを送信する能力は、最近1億5000万ドルを調達したSigFoxなどの企業によって徐々に整備されていくが、しかしながら今の分散データベースのアーキテクチャの多くは、市場が求めるそんな帯域にマッチできるほどの、高速なデータ処理と出力の能力を持っていない。

シアトルのBashoは、同社のNoSQLデータベースRiak TSの最新リリースで、そんな問題の一部を解決しようとしている。TSはtime-series(時系列)の頭字語で、データのユニークなキーヴァリューがタイムスタンプであり、それはそのデータが作られた日時を指している。TSシステムはこれまでもBashoのエンタープライズクライアント(Uber, AT&Tなど)にしばらく使われてきたが、今回のオープンソースリリースによって、そんなデータタイプを初めて扱うデベロッパーでも、気軽に利用できるようになった。

MongoDBやDataStaxなどの同業企業と違ってBashoはこれまで、わずか2500万ドルの資金しか調達していない。明らかに同社は、時系列データを扱うという独自性が、NoSQLデータベースの業界で強力な差別化要因になる、と信じている。

今回のニューリリースは、ApacheのクラスターフレームワークSparkを統合し、SparkとRiak TSにおけるインメモリ処理のためのデータの、自動的分散化と対話をサポートしている。

多くの人にとってこれは些細なことと思えるかもしれないが、センサーからの大量の時系列データを扱う者にとっては、大規模な分散化データが、コンピューターの実動時にすら、長いリード/ライト時間の原因となり、分散化による冗長性が効率を殺してしまう。

ソリューションとしては、ハッシュランクを使ってデータのキーをデータクラスター全体にわたって均一に分散するやり方が多い。それによって、大規模なノード集合全域にわたる同じタイムレンジからのデータを効率的に入力するが、一方でレンジへのアクセスが高負荷な操作になる。

BashoのCEO Adam Wrayによると、Riak TSが使っているユニークな分散化システムはユーザーに、タイムスタンプのある、あるいはそのほかの連続的な、データの処理における有利性を与える。

“われわれはデータの配置を最適化し、特定のノードが特定のレンジのデータを得るようにしている”、と彼は語る。つまりこのような配置によって、一定のタイムレンジからのデータのフェッチが、より少ない操作ですむようにしている。

新しいリリースのREST APIによって個々のデベロッパーが利益を得るだけでなく、Bashoがエンタープライズの世界で歓迎される要因は、Riak TSの、既存のSQLデータベースコマンドとの互換性だ、と彼は考えている。

“それは正規のSQLコマンドであり、一部のCQLや、SQLのわれわれ独自の変種ではない”、とBashoのCTO Dave McCroryは述べる。“われわれは、人びとがいちばん多く使いたがる従来的な操作をサポートする”。

たしかに、いちばん多く使われているSQL操作をサポートすればレガシーユーザーやエンタープライズの多くにとって魅力的だが、多くのエンタープライズユーザーはSQLプラットホームの上に内製のカスタムソリューションを乗っけており、それがエンタープライズ世界におけるRiak TSの広範な採用を妨げるかもしれない。

Riakのノードは仮想と物理的、両方のマシンにまたがって分散化でき、またMicrosoftのAzureやAmazon Web Servicesなどのプラットホーム上の、クラウドインスタンスの上でもそれは可能だ。

Bashoの主張によると、時系列データの処理では、Riak TSの方がApacheのNoSQLデータベースCassandraなどよりも50%は速い。本誌TechCrunchはこの主張を検証していないが、今回オープンソース化されたことにより、Rial TSシステムのパフォーマンスゲインは多くのユーザーにとって明らかになるだろう。

このシステムが内包している強力な事故回復力が、エンタープライズユーザーたちのデータベース乗り換えの十分な動機になるか、それはまだ分からない。Riak TSでは各クラスターが同一データのコピーを三つ抱えるので、マルチクラスターのリプリケーションが天文学的な数の操作になることもありえる。しかし十分なスケーラビリティがあれば、これによって高いアップタイムと低い誤り率が保証される。ただしそれに要する費用は、小さな企業が尻込みするほどの額だろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

データを発見しそれらの起源・出自を調べるLinkedInの社内ツールWhereHowsがオープンソース化

linkedin-chocs

LinkedInが今日(米国時間3/3)、WhereHowsをオープンソース化した。WhereHowsは主に同社の社員が、同社が生成するデータを見つけ、また同社のさまざまな内部的ツールやサービスで使われているデータ集合の出自を調べるために使っている、メタデータツールだ。

今では多くの企業が毎日のように大量のデータを作り出しているから、それらの情報のフローを全社的に管理することがほとんど不可能になっている。データウエアハウスに保存するのはいいけれども、結局のところ、同じようなデータ集合が大量に集積したり、元のデータ集合のいろんなバージョンが散乱したり、いろんなツールで使うためにデータ集合がさまざまに変形されていたりする。まったく同じデータが、名前やバージョンを変えて複数のシステムにあることもある。だからたとえば新製品開発をこれから始める、というとき、あるいは単純に役員が見るためのレポートを作ろうとするとき、どのデータ集合を使えばよいのか、よく分からないことが多い。

2016-03-03_0839

LinkedInのShirshanka DasとEric Sunによると、同社もまさしく、この問題に直面していた。そこで彼らは、WhereHowsを開発した。それは、LinkedInのような大きな企業で、データに何が起こっているかを常時追跡するための、中央的リポジトリ兼Webベースのポータルだ。今では中小企業ですら、大量かつ雑多なデータの整理や管理に悩まされているだろう。LinkedInでは、WhereHowsが現在、約5万のデータ集合と14000のコメントと3500万のジョブ実行の、ステータスに関するデータを保存している。それらのステータスデータは、約15ペタバイトもの情報に対応している。

LinkedInはHadoopの大ユーザーだが、このツールはほかのシステムのデータも追跡できる(Oracleデータベース、Informatica、などなど)。

WhereHowsはAPIとWebの両方でアクセスできるから、社員たちはデータ集合の出自や由来を視覚化したり、注釈を加えたり、いろんなことができる。

DasとSunによると、LinkedInは、そのサービス本体に属していないプロダクトをこれまでも長年、オープンソース化してきた。その基本的なねらいは、会話を喚起することだ。ビッグデータの大きなエコシステムがあれこれのツールを採用すると、同社もそのことで結果的に得をする。これまでぼくが取材してきた多くの企業と同様に、LinkedInでも、オープンソースが同社の技術のブランドイメージを高め、すぐれた人材の獲得を容易にするのだ。

2016-03-03_0844

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

“部屋を片付けられない病”ならぬ“データを片付けられない病”になりつつある現代企業を救うKomprise…ストレージとデータ管理のスケーリングを自動化/効率化

userinterface1

大量のデータを保存することには、費用が伴う。正しい情報管理の方法を実践していない企業では、その費用も大きい。しかしここでご紹介するKompriseは、企業が抱えるビッグデータをすっきりと分かりやすく整理して、余計なストレージ費用が発生しないようにする。

サンフランシスコ生まれのKompriseは今ベータを準備中で、最近600万ドルのシリーズAをCanaan Partnersから調達したばかりだ。その同社のサービスとは、データの保存と組織化と分析を、オンプレミスのサーバやクラウドにおいて、高い費用効率で自動化することだ。新たな資金は、陣容の増員に充てられる。〔Kompise→comprise→すべての部分要素から全体を構成すること。〕

同社のファウンダはCEOがKumar Goswami、COOがKrishna Subramanian、そしてCTOがMichael Peercyだが、彼らにとってKompriseは三つめのスタートアップだ。その前の仮想デスクトップサービスKavizaは2011年にCitrixに買収された

Subramanianは曰く、“前の二つのビジネスは、データに関して企業が抱える別の問題に焦点を当てていた。最初のスタートアップは営業のためのファイル共有アプリケーションだったし、その次のは、仮想デスクトップで高価なSAN(storage area network)を使わずに済ませるサービスだった”。

“それらを通じて顧客から学んだのは、データに関して今日の彼らが抱える最大の問題が、日々のデータの増加量が、かつてなかったほどにすさまじく多いことだ”。

そのため今では、企業の年間のIT予算の1/4が、ストレージとデータ管理に充てられている。しかも、それらのデータの多くが、各担当部署で蛸壺(たこつぼ)入りしているだけで、まったく活用されていない。…Kompriseのファウンダたちは、そんな状況を至るところで見た。

そこでKompriseが考えたのが、オンプレミスのサーバの容量をクラウド上のストレージで拡張する、というソリューションだ。それによってかえって、必要なデータへのアクセスやデータの管理が容易になる、と彼らは展望した。

CTOのPeercyによると、“Kompriseを使えば企業は最大で70%のコスト削減を図り、しかも効率をアップできる。またDevOpsチームのある企業では、新しいアプリケーションをクラウドで動かしたいが必要なデータはオンプレミスにある、という状況を改善できる。Kompriseのサービスにより、データの保存と管理が自動化そして効率化され、つねに必要なところにデータがあるという状態を実現できる”、ということだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa