タグ

databaseに関するminotonのブックマーク (294)

  • 決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ

    エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 記事のポイントは 残高を管理をするテーブルは作らず、ト

    決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
  • サイボウズさんの開運研修(データベース)で話してきました

    2024 ( 17 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 東京都オープンデータカタログサイトのCSVを使ってLOAD DATA LOCAL INFILEの練習をする サイボウズさんの開運研修(データベース)で話してきました オプティマイザヒント

  • SQLが重いときに見るお気軽チューニング方法

    SQLのチューニング方法 昔Qiitaで書いたものをzennうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく(自分の経験則)、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって当にインデックスがないことが原因なのか?を熟考する必要があります。(例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話) また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加

    SQLが重いときに見るお気軽チューニング方法
  • AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方

    リーガルテック領域のリーディングカンパニーである株式会社LegalForceが、「検索インフラTechTalk!」を開催しました。インフラ領域の中でも「検索インフラ」にフォーカスした今回は、検索インフラに関する具体的な事例や取り組みについて各スピーカーから発表がありました。野口真吾氏は、AWSを用いたデータレイクの基礎について紹介しました。 企業規模に関係なく起こるデータのサイロ化 野口真吾氏(以下、野口):みなさんこんばんは。日は「検索インフラ Tech Talk!」ということで、検索インフラから少し広げた話題にはなるんですが、「AWSを用いたデータレイクの基礎」というお話をします。よろしくお願いします。 最初に簡単に自己紹介します。アマゾンウェブサービスジャパンでスタートアップ担当のソリューションアーキテクトをしている野口真吾と申します。Twitterでは@nogというIDを使って活

    AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方
  • Amazon Redshift の 可用性と耐久性について | DevelopersIO

    はじめに 先日お客様よりRedshiftの構成や可用性、耐久性、データの復元などのご質問をいただきましたので 想定される障害についてどのような復旧対応が行われるのかまとめました。 引用はAmazon Redshift のよくある質問の 可用性と耐久性 から引用しています。 ドライブ障害 Q: 1 つのノードのドライブに障害が発生した場合、データウェアハウスクラスターの可用性とデータ耐久性はどうなりますか? Amazon Redshift データウェアハウスクラスターはドライブに障害が発生した場合でも継続して利用できますが、特定のクエリに対するパフォーマンスがわずかに低下します。ドライブに障害が発生すると、ノード内の他のドライブに格納されている障害ドライブのデータの複製が、透過的に使用されます。さらに、データを正常なドライブに移動させるか、移動できない場合はノードの交換が行われます。 単一ノ

    Amazon Redshift の 可用性と耐久性について | DevelopersIO
  • AWS | RDS(Multi-AZ, リードレプリカ, バックアップ, リストア) - わくわくBank

    RDSの基的な使い方について解説します。「DBインスタンスの作成」「設定変更」「バックアップとリストア」について確認します。 RDSの基礎知識 特徴 以下のような特徴があります。 自身で全て作業するのに比べて、構築、運用の手間が少ない。 ソフトウェアパッチの適用、バックアップが自動で行われる。 OSにはログインできない。 DBの設定は パラメータグループ を通じて行う。 Multi-AZ による フェイルオーバー が可能。 リードレプリカ による 読み取りスケーリングの拡張 が可能。 参考 Amazon Relational Database Service (​Amazon RDS) とは? Multi-AZとリードレプリカ RDSを利用する上で、 Multi-AZ と リードレプリカ の役割を押さえておくと良いです。

    AWS | RDS(Multi-AZ, リードレプリカ, バックアップ, リストア) - わくわくBank
  • データ基盤チーム0人で運用は回るのか?! 前人未踏チャレンジ・クックパッドデータ基盤のすべて2020 - クックパッド開発者ブログ

    技術部データ基盤グループの青木です。 ここ1、2年はなぜか成り行きでBFFをでっちあげたり、 成り行きでiOSアプリリニューアルのPMをしたりしていたので あまりデータ基盤の仕事をしていなかったのですが、 今年は久しぶりに業に戻れたのでその話をします。 突然の1人チーム、そして0人へ…… 今年のデータ基盤チームは消滅の危機から始まりました。 間違いなく去年末は5人のチームだったと思うのですが、 メンバーがイギリスへグローバルのデータ基盤チームを作りに行ったり、 山へ検索システムを直しに行ったり、川へレシピ事業の分析業務をやりに行ったり、 海へ広告のエンジニアリングをしに行ったりするのをホイホイと気前よく全部聞いていたら、 なんと4月から1人だけのチームになってしまいました。 事はそれで終わりません。 恐ろしいことに10月にはわたし自身も育休に入ることになったので、 10月はデータ基盤が0

    データ基盤チーム0人で運用は回るのか?! 前人未踏チャレンジ・クックパッドデータ基盤のすべて2020 - クックパッド開発者ブログ
  • shiodaifuku.io

    Webエンジニアのブログです。

    shiodaifuku.io
  • SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる

    最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat

    SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
    minoton
    minoton 2020/12/16
    dbms(&オプション)によっても挙動が違うしねえ
  • 本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita

    起きた事 番環境のデータ調査の依頼を受けた。その調査を受ける前に、それとは別で不要データをDBから削除する作業をMySQL Workbenchで行っていた。 DBで、データ調査を行う際にMySQL WorkbenchでSQLのselectと間違えてdeleteを実行してしまい、Tableを1つ丸ごとDeleteしてしまった。 ON DELETE CASCADEが親テーブルに設定されてしまっていたため、さらに4つのTable dataが芋づる式に消えてしまった。 ON DELETE CASCADEの説明としては、この記事がわかりやすかったです。 https://www.dbonline.jp/mysql/table/index11.html テーブルの構成(テーブル名などは例として挙げていて、実際のものとは多少異なります) 正しい設定 usersテーブルでuserを削除した時に、そ

    本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita
    minoton
    minoton 2020/12/03
    ミスはミスとして、この制約は罠だなあ
  • ブロックチェーン・5G - BPO・受託開発 | 株式会社ディネクション diNextion Ltd. 鼎田富生有限公司

    ブロックチェーン・5G | 株式会社ディネクションは、ブロックチェーン技術を使って、日社会全体にブロックチェーン技術を応用します。 トランザクションと情報をデジタル化することで、データを保護しコストを削減、社会全体にブロックチェーン技術を応用します。 製品トレーサビリティー 全プロセスで製品のトレーサビリティとトラッキングを行います。偽造防止システムは、IoTや偽造防止ラベルなどを組み合わせ、改ざんできないトレーサビリティー情報と取引履歴のデータを作成し、検証と監査をサポートします。 サプライチェーンファイナンス 売掛金や前払金などの取引情報を、メーカー、サプライヤー、金融機関の間で安全に共有することができず、信用を共有することが出来ず、中小企業の運転資金、設備資金融資の調達が困難です。メーカーが率先してシステムを導入することで、取引、物、資金のフローを垂直統合し、改ざんできない信頼性の

    ブロックチェーン・5G - BPO・受託開発 | 株式会社ディネクション diNextion Ltd. 鼎田富生有限公司
  • BaaSを比較したい人向け~Azure vs AWS vs IBM (2019/12更新)

    事前知識:そもそもBaaSってなに? サイトのメインテーマであるBaaS(バース)について、事前にある程度理解したい方は、下記の記事を参考にしてください。 ▼参考記事 サクッと学ぶ「BaaS(Blockchain as a Service)」とは何か? BaaS(バース / Blockchain as a Service) BaaSの定義は、使う側によってさまざまですが、サイトではブロックチェーン(アプリ)開発を容易にするためのクラウドで提供されるサービス をBaaSと呼んでいます。 結論 AWS,Azure,IBMを比較して何を選べばいいのか、結論から書かせて頂きます。 これらは、あくまで私的見解になりますのでご了承ください。また、細かいユースケースによっても選ぶ基準は変化します。自社のプロジェクトに対し、どのBaaSを選べばよいのか、弊社でも相談を受け付けていますので、お気軽にお問

    BaaSを比較したい人向け~Azure vs AWS vs IBM (2019/12更新)
  • ブロックチェーン活用事例10選 ― 2019年はブロックチェーン3.0時代へ|ビジネスブログ|ソフトバンク

    ブロックチェーン活用事例10選 ― 2019年はブロックチェーン3.0時代へ</h1>\r\n"}}" id="text-928c244646" class="cmp-text"> ブロックチェーン活用事例10選 ― 2019年はブロックチェーン3.0時代へ <span class=\"biz-smb-fs-p1\"><b>ビジネスブログ「 Future Stride」編集チーム</b></span></p>\r\n<p>ビジネスブログ「 Future Stride」では、ビジネスの「今」と「未来」を発信します。</p>\r\n<p>DXや業務改革をはじめとしたみなさまのビジネスに「今」すぐ役立つ最新トレンドを伝えるほか、<br>\r\n最先端の技術を用いて「未来」を「今」に引き寄せるさまざまな取り組みにフォーカスを当てることで、すでに到来しつつある新しいビジネスの姿を映し出していきます。

    ブロックチェーン活用事例10選 ― 2019年はブロックチェーン3.0時代へ|ビジネスブログ|ソフトバンク
  • データベースを遅くするための8つの方法

    はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが1時間越えに化けることもザラにあるので原

    データベースを遅くするための8つの方法
    minoton
    minoton 2020/11/15
    “UUIDなどユニークでランダムなキーかサロゲートキーではなくナチュラルキーを使うと良いでしょう”
  • 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

    自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

    1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
  • SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita

    2020/9/30追記 記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか? 今回は、そんな方々にこそ

    SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
  • 注目すべき最新データベース技術(パート1)

    この記事は、著者の許可を得て配信しています。 https://blog.pragmaticengineer.com/the-developer-culture-test/ 私はデータベースの大ファンで、いわゆる「NoSQL」データベースに関するを書いたり、影響力の高い分散型データベースRiakに携わったりと、技術職として最も実りある年のいくつかを過ごし、昨年は楽しみのためにPurpleというデータベースを構築したりもしました。 当然のことながら、私はTwitterやReddit、HackerNewsなどをさらっと読む場合、データベースやDB関連ツールの新しくて刺激的な開発に常に気にして見ています。今回の記事では、私が興味をそそられる最近登場した3つのデータベース技術についてお話したいと思います。 TileDB Materialize Prisma 後半では次の3つについてお話したいと思っ

    注目すべき最新データベース技術(パート1)
  • PayPayでのDynamoDB活用事例について

    Presented by: Tomoki Nishinaka, Yu Zhouxun PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの設計からリリースまでにおける検討プロセスや、DynamoDBを使った開発/運用手法、及びテーブル設計のtipsについてご紹介します。

    PayPayでのDynamoDB活用事例について
  • Amazon RDS/Auroraをクローンするシステムを作った話 - クックパッド開発者ブログ

    こんにちは、技術部SRグループの菅原です。 最近、Ninja650からNinja1000に乗り換えました。パワーがあるせいで3速発進・4速発進が平気でできてしまい、シフトワークがどんどん下手になっています。精進したいものです。 この記事では、Amazon RDS/Auroraをクローンするシステムを作った話を書きます。 Amazon RDS/Auroraをクローンするシステム サービス開発を行っていると、調査や検証でプロダクション環境で使われているデータベースが必要になることがあります。開発環境やステージング環境にもデータベースは存在するのですが、プロダクション環境のデータでしか再現しないバグの調査や、プロダクション環境のデータ量でのスキーマ変更の負荷の検証など、開発環境やステージング環境のデータベースではできない作業も多いです。しかし、オペレーションミスや個人情報へのアクセスを考えると、

    Amazon RDS/Auroraをクローンするシステムを作った話 - クックパッド開発者ブログ
  • 事業に貢献するデータ基盤を作ろう・考え方編 / data_engineering_study_2

    Data Engineering Study #2「データ収集基盤とデータ整備のこれまでとこれから」https://forkwell.connpass.com/event/182769/ 作成者 :しんゆう@データ分析とインテリジェンス Twitter:https://twitter.com/data_analyst_

    事業に貢献するデータ基盤を作ろう・考え方編 / data_engineering_study_2
    minoton
    minoton 2020/08/20
    考え方として