タグ

databaseに関するk_oshimaのブックマーク (8)

  • すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp

    すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ⁠⁠、全銀システム通信障害の詳細を説明 全国銀行資金決済ネットワーク(以下、全銀ネット)とNTTデータは12月1日、2023年10月10日~11日にかけて全国銀行データ通信システム(以下、全銀システム)で発生した通信障害に関する報道関係者向けの説明会を開催しました。件についてはNTTデータが11月6日に行った途中経過報告の内容をもとにレポートしましたが、今回、全銀ネットとNTTデータが揃って会見を行ったことで、より詳細な障害の原因が判明したので、あらためてその内容を検証してみたいと思います。 説明会の登壇者。左から、全銀ネット 企画部長 千葉雄一氏、事務局長兼業務部長 小林健一氏、理事長 辻松雄氏、NTTデータ 代表取締役社長佐々木 裕氏、取締役副社長執行役員 鈴木正範氏 なお、全銀ネットとNTTデータは、今回の障害に関して金融

    すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp
  • 基本4情報での名寄せは難しい|MORIDaisuke

    先日は住所の件でお楽しみでしたね。 私も楽しくなってしょうもないツイートをしたところ、@masanorkさんから有用な情報をいただいてしまいました。 異体字に加えて外字も根深いですし、日付型に収まらない住基の生年月日とか、屋号を含んだ個人事業主の口座名義とか、外国人氏名における住民登録のアルファベットと口座名義のカタカナとの解離とか、旧姓併記の例外処理とか、文字列型に刻まれたバッドノウハウの塊ですね https://t.co/GOaytijfst — Masanori Kusunoki / 楠 正憲 (@masanork) June 6, 2023 このとき、私はごく簡単な「名寄せの難しさ」の社内研修資料を作っている最中だったのですが、この情報が大変参考になりました。 一方、私だけが得をしているのがなんとなくムズムズしてきたので、ここにアウトプットしてスッキリしようと思います。 なお、住所

    基本4情報での名寄せは難しい|MORIDaisuke
  • Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita

    TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ! Amazon AuroraAWSの中で利用可能なマネージド(=運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー

    Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
  • Clojureの作者が作ったデータベースDatomicが凄い

    プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ

  • Manhattan, our real-time, multi-tenant distributed database for Twitter scale

    Manhattan, our real-time, multi-tenant distributed database for Twitter scale As Twitter has grown into a global platform for public self-expression and conversation, our storage requirements have grown too. Over the last few years, we found ourselves in need of a storage system that could serve millions of queries per second, with extremely low latency in a real-time environment. Availability and

    Manhattan, our real-time, multi-tenant distributed database for Twitter scale
  • Handling Growth with Postgres: 5 Tips From Instagram

    Welcome to the Instagram Engineering Blog, where we share insights on building and scaling our service. As we’ve scaled Instagram to an ever-growing number of active users, Postgres has continued to be our solid foundation and the canonical data storage for most of the data created by our users. While less than a year ago, we blogged about how we “stored a lot of data” at Instagram at 90 likes per

    Handling Growth with Postgres: 5 Tips From Instagram
  • InstagramのIDシャーディングについて

    約1年前の Instagram Engineering Blog で ID のシャーディングについて解説されていたのでメモ。 Sharding & IDs at Instagram http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram 背景 毎秒大量に行われる写真投稿やユーザーの行動をデータベースに保存するために、Instagram ではシャーディングを行なっている。 データベースにデータ格納するにあたり、シャードが別であっても、写真といったコンテンツごとにユニークなIDを振らないといけない。 Before writing data into this set of servers, we had to solve the issue of how to assign uniqu

  • データベースの歴史(概要)<データベースの歴史<歴史<木暮仁

    シリーズの構成 1 データベースの歴史(概要-全体の流れ) 2 階層型データベースとネットワークデータベース 3 関係データベース 4 オブジェクト指向データベース 5 XMLデータベース 6 多次元データベースとデータウェアハウス 7 インメモリデータベースと列指向データベース 付 年表 データベースそのものはデータの持ち方だけであり、特別な技術を伴うものではない。そのデータをアクセスするための言語やそれを解釈して実行するためのソフトウェア、データの一貫性や可用性を保つためのシステムが必要になる。それをデータベース管理システム(DBMS:Database Management System)という。 また、データベースを実現するには、DBMSの理論だけでなく、それをソフトウェアとして作成する必要があるし、それはOSや言語に影響をうける。さらにハードウェアに実装する必要がある。 ここでは、

    k_oshima
    k_oshima 2015/04/17
    ざっくり俯瞰。だいたいあってる
  • 1