検索基盤をElasticsearchに安全に置き換えるためにやったこと - Enjoy Architectingはじめに 仕事で関わっているプロダクトがユーザ検索をDBで実装していたので、 今後のためにElasticsearchクラスタを導入したが、 安全にリリースするためにダークローンチとFeature Toggleを活用したので、 そのときの知見をまとめた。 資料 speakerdeck.com 参考 cloudplatform-jp.googleblog.com martinfowler.com
「書き直したい」 をグッと抑えて小さな改善を積み重ねよう | Recruit Tech Blog
この記事はRECRUIT MARKETING PARTNERS Advent Calendar 2017の投稿記事です。 こんにちは、2016 年中途入社の nobuoka です。 ソフトウェアエンジニアとしてキッズリーの開発に携わっています。 先日読んだ 『「書き直した方が早い」 は 9 割のケースで間違いだった』 というブログ記事に触発され、最近考えていた 「小さな改善を繰り返すこと」 について書き記します。 意識の話に寄っていて技術的な話ではないですが、是非読んでみてご意見をお寄せいただければと思います。 後半では、実際の製品開発での取り組みも紹介しています。 伝えたいことは一つだけ。 タイトルにある通り 「どうにも手が負えないから新たに書き直したい」 という気持ちに対して、一度それをグッと抑えて小さな改善を積み重ねよう ということです。 背景 : 新しく書き直すか、小さな改善を繰り
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
スタディサプリENGLISH 大規模改修の裏側 | Recruit Tech Blog
ここからはサーバーサイドにフォーカスした大規模改修の詳細についてご紹介します。 大規模改修前のサーバーサイドの構成 当時はこのようなレイヤードアーキテクチャを採用していました。縦はController、UseCase、Repository、データ層で区切り、横はコンテキスト毎にパッケージで区切られています。当初から複雑な仕様・要件でしたが、それぞれの影響範囲は明確となっているので、新規に参画するエンジニアにとっても十分に見通しの良いものとみなしていました。 事実、この設計で２年ほどエンハンスを続けてきましたが、大きな問題が発生することはありませんでした。 なぜ大規模改修が求められるようになったのか 『TOEIC対策コース』の新設が決まり、その仕様を詰めていくうちに次のことが浮き彫りとなってきました。 TOEIC対策コースと日常英会話コースとでは『レッスン』と『トレーニング』のツリー構造が根
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
DatastoreとFirestoreとApp Engineの関連 - Qiita
注意書き この記事は2017年12月の記事です。 現在、Google Cloud FirestoreはUPDATEされて、以下の内容とは異なります。 新しい記事はお待ち下さい！ 記事 Cloud Firestore がBetaで公開されました。 Cloud Firestoreは、Firebase Realtime Databaseの後継に当たるサービスです。 Firebase Realtime DBに存在していたリアルタイム更新やデータベースルール, オフライン機能や、Firebase Authとの連携などを受け継いでいます。 大きく変わったのはバックエンドです。 Firebase Realtime DBは、もともとGoogleが作ったものではなく、Googleが買収したサービスでした。 買収後、FirebaseはAuth, Push通知, Analytics, Remote Config
クックパッドのデータ活用基盤 - クックパッド開発者ブログ
インフラ部 & 技術部の青木峰郎です。 クックパッドでは全社的にAmazon Redshiftを中心としたデータ活用基盤を構築しています。 今日はその全体像についてお話ししたいと思います。 データ活用基盤の全体像 まず、以下にクックパッドのデータ活用基盤の全体像を示します。 大きく分けると入力が2系統、内部処理が1系統、出力が3系統あります。 入力はMySQLからのインポートとログのロードがあり、どちらも独自に構築したシステムで行われています。 DB内部のデータ処理はSQLバッチのみです。 そして出力は管理画面やBIツールからのアクセスとバッチ処理によるエクスポートに大別できます。 以下1つずつ説明していきましょう。 入力その1: MySQLインポートシステム MySQLからRedshiftへのマスターテーブル取り込みにも独自のインポートシステムを使っています。 このインポート処理には、つ
大規模データ移行の失敗を防ぎたい。計画やプログラム、インフラの注意点と、ありがちなこと - Qiita
仕事柄、大規模なデータ移行を何度か経験してきました。 データ移行、特にDBのマイグレーションでもなく、 システム移行のときのようなデータ構造の変更を伴う際には気をつけることがたくさんあります。 クラウドではだいぶ楽になりますが、 特にオンプレミスで検討せざるを得ない皆さんに気をつけないといけない点を共有します。 スケジューリング編 最初から検討し始めよう 開発プロジェクトにおいてシステム移行だけで4割の工数がかかると言われています。 しかし、新規システム部分の開発で頭が一杯になっていると、重要度の割に移行部分が後回しにされがちです。 移行用プログラム、移行用サーバ手配はもちろん、新規、既存システムへの影響も検討しないといけません。 できればプロジェクト開始時から人をアサインして計画を立てていきましょう。 移行自体が一つの開発プロジェクト相当です。頑張りましょう。 後半になって移行計画を立て
Rails アプリでオンラインでカラムの削除やリネームを行うには - eagletmt's blog
前提知識 Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。 というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。 機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べら
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
PostgreSQLの実行計画を読み解くための参考資料集 - ぱと隊長日誌
はじめに PostgreSQLは商用DBに比べて書籍が少なく、まとまった情報が入手しにくいです。また、有志の方がPostgreSQLに関する資料を公開していますが、散在しており、せっかくの有益な情報にアクセスしにくい状況にあります。 そこで、本エントリではPostgreSQLの実行計画に焦点を絞り、公開されている有用な資料（書籍含む）をまとめました。読み返したい資料を探しやすくするため、内容のポイントも併せて紹介してます。 本エントリをきっかけに、これらの資料がさらに活用されることを願っています。 前提 各資料の前提としているPostgreSQLのバージョンは異なることにご注意ください。調査対象のPostgreSQLのバージョンが異なれば、状況は変わっているかもしれません。 各資料には内容の重複があり、ほぼ同一内容の場合もあります。重複している内容についてはポイントから割愛することがありま
システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel お知らせ #mackerelio
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
Hadoop の時代は終わってないけど、使いどころは限定されてきたかもしれない - ブログなんだよもん
id:shiumachi さんが書かれてる下記の記事がとても良かったです。 shiumachi.hatenablog.com 私自身もSparkを触る前は「Hadoop == MapReduce」と思ってましたが、どちらかというとYARNやHDFSがHadoopファミリの核だと最近は思いますし その意味でのHadoopは全然終わってないと思います。記事の中で書かれてる通り、ある意味ではさらなる進化を遂げて花開いてる状態かな、と。 ただ、Twitterにも少し書いたんですが一方で「猫も杓子もHadoop！」の時代が終わりつつあるのも事実かな、と思います。 もうちょっというとHadoopに限らず巨大スケールの分散システムの用途が収斂してきたのかな、と。 HadoopやGoogle MapReduce登場時のと違い、ストレージI/Oは133MB/sとかの単位で争ってたHDDからストレージに代わっ
時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
DBeaver Community | Free Universal Database Tool
Basic support for relational databases: MySQL, SQL Server, PostgreSQL and others Data Editor SQL Editor Database schema editor DDL Basic ER Diagrams Basic charts Data export/import Task management Database maintenance tools All DBeaver Community featuresAdvanced securityAdvanced support for relational databasesConnection through ODBC driversNoSQL databases support: MongoDB, Cassandra, Redis, Couch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQL Performance Monitoring
RDBアンチパターン // Speaker Deck
