SpreadsheetDB development has been discontinued, many thanks to everyone who supported the project.
SpreadsheetDB development has been discontinued, many thanks to everyone who supported the project.
こんにちは、みんなのウェディングに出向中の小室 (id:hogelog) です。 今回はクックパッドとみんなのウェディングで利用しているデータベースドキュメント管理システム dmemo を紹介します。 https://github.com/hogelog/dmemo dmemo を作成し導入した経緯 私は2016年3月頃からみんなのウェディングで Redshift, bricolage, embulk, re:dash 等を利用したデータ分析基盤の構築を進めています。 (みんなのウェディングのデータ分析基盤の現状 - みんなのウェディングエンジニアリングブログ) 社内の誰でも扱えるデータベース、データの集約・計算・加工、ダッシュボードの作成、クエリの共有などは上記ブログ記事でも書いたように Redshift, bricolage, embulk, re:dash 等を組み合わせることで実現
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか? オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました(参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」)。 ホワイトペーパーでは、HDDの代わり
Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)~キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 (この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題」の続きです) キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に(友人たちの)情報を集めることがで
もう1つの、DBのかたち、分散Key-Valueストアとは:分散Key-Valueストアの本命「Bigtable」(1)(1/3 ページ) RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
データベース設計はいつ、何をポイントに行うか:ゼロからのデータモデリング入門(4)(1/3 ページ) 前回までは、データベース設計の歴史的背景からデータベース設計の有効性までを解説しました。今回は、システム開発ライフサイクルと照らし合わせ、それぞれのフェイズで必要となるデータベース設計について、お話をします。 どの段階でどう設計すればいいのか 前回、データベース設計は自社のビジネス活動を理解している自社内の人間がやるべきであり、情報システム部門の存在意義を高めるために必要な技法であるとお伝えしました。しかし、システムの外部委託が多いというのもまた事実です。 筆者の職場では、お客様からデータモデリングに関するご相談をいただく際、最初に「貴社のデータモデルを拝見させてください」というお願いをします。システム開発を外部委託しているケースでは多くの場合、形として残っているのは「物理データモデル」で
Webベースのデータベースフロントエンドとして有名なものはphpMyAdminだろう。だが開発の現場ではMySQLが利用されることもあれば、PostgreSQLが使われることもある(他のデータベースももちろんあるが)。その度にフロントエンドが異なるのは面倒だ。 管理画面 各種レポートの出力にも対応したこちらを使ってみるのはどうだろう。 今回紹介するオープンソース・ソフトウェアはvFront、細かな設定が可能なデータベースフロントエンドだ。 vFrontはPHPで作られたWebベースのデータベースフロントエンドだ。MySQLのみならず、PostgreSQLにも対応しているという特徴がある。さらにただデータベースのデータを全て編集できるという訳ではなく、テーブルを指定してCRUDを指定できるという利点がある。 テーブル構造確認 例えば修正されるとまずいテーブルや、見られることも問題があるテーブ
業務システム構築にデータベース(以下、DB)アクセスは欠かせないが、筆者の場合、WebアプリケーションやWindowsアプリケーションからRDBMSを直接使うのではなく、間にXML Webサービスを挟んで使うような構成を提案するように心掛けている。 例えば、図1のような構成である。本稿ではこのようなXML Webサービスを活用したDBアクセスの実装について解説する。 このような構成によりDBアクセスをXML Webサービスで一元管理すれば、次のような利点が生まれる。 DBとの接続に必要なミドルウェアの設定がXML Webサービスのサーバだけに限られるため、導入の手間も少なくて済む DBアクセス・ロジックをXML Webサービスに集約することで、想定外のDBアクセス・コードを除外できる UI(ユーザー・インターフェイス)部分を除外した形で実装することになるので、ロジック部分が明確になる(MV
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはオークション事業部プラットホーム技術のチャックです。 オークションでは一部サービスに RDBMS の MySQL を使ってサービスをご提供させていただいております。 オークションでは多くのお客様よりアクセスを頂いておりますので、大量の更新、参照の処理速度に優れた MySQL を選択し、お客様にストレスなくサービスをご利用いただけるよう 日々業務に取り組まさせていただいております。 しかし、精密機器には故障がつきもので、サービス運用の観点からは 「機器が故障するのはしかたない、しかしそれをいかに早く復旧させるか」 といったことを念頭に入れております。 実際には、障害が起こってから復旧させるのではなく、障害が発生した場合に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く