WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が
WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が整っているわけではないです。 徳丸先生は、一般的な開発者には最低限どのレベルのセキュリティ知識を求められていますか？ 回答の難しい質問ですが、ここは本音をさらけ出したいと思います。 私が「安全なWebアプリケーションの作り方（通称徳丸本）」を出したのが2011年3月でして、それから13年以
NewSQLはデータベースに革命を起こすか - NetflixにおけるCockroachDBのユースケース｜ミック
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発― 処理性能456万TPSと応答遅延219ナノ秒を実現 ― 日本電気（株）と（株）ノーチラス・テクノロジーズはNEDOの「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発」（以下、委託事業）において、世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」（以下、劔）を開発しました。 劔は、次世代のデータベースに用いられるハードウエア環境（メニーコア・大容量メモリーなど）に適合したシステムであり、ハードウエアの性能が向上するほどシステムの性能も高まる特性を有しています。32以上のコア数を有するハードウエアにおいては、世界最速レベルの処理性能456万TPSと219ナノ秒の応答遅延を実現しました。 劔の導入によって、複雑なバッチ処理とオンライン
SQL学習モチベを爆上げする「SQLテスト制度」を導入している話 - AppBrew Tech Blog
こんにちは、最近はアプリグロースを担当しているabeshi（@abeshi_official）です。 美容のプラットフォーム「LIPS」を運営するAppBrewでは非開発職のSQL習得に力を入れています。誰でもRe:dashやログを触れる状態になっているし、それぞれのDBに何がどう入っているかを共有するためのドキュメントも存在しています。 「非開発職もSQL書けるように頑張ろう！」と掲げたところで、当の本人たちは毎日仕事が忙しくなかなか時間も取れない上に明確な目標がないといまいち学習モチベーションを保つことができません。そこで弊社が導入したのが「SQLテスト制度」です。 ✍️SQLテスト制度とは SQLの学習到達度によってレベルごとに分けたテストで、合格すると給与が上がります。 *1現在は二つレベルが存在していて、 【レベル2】... 初学者向けでwhere・joinなど基本的な文法が使え
SQLで大量のテストデータ作成 - Qiita
以前に SQLでテーブルデータの一括作成、複製 という記事を書いたのですがもう少しかみ砕いて、かつPostgreSQLにも対応した内容で書き直してみます。 RDBMSを利用したアプリケーションを開発していて数千件を超える大量のデータを作成する必要が発生した場合に知っておくと便利なテクニックの紹介です。なお、以下のようなケースを想定しています。 SQLのパフォーマンス検証のために大量のレコードが必要 1テーブルに100万件以上 動作検証・評価作業のためにテスト内容に準じたデータが一定数必要 1セット100件を100セット 事前準備 SELECT文の 直積(CROSS JOIN) を利用します。 事前に一定数のレコードを保持するテーブルが必要です。 ここでは sample というテーブルを作成して 直積(CROSS JOIN) のSELECT文に利用します。 MySQLとPostgreSQLで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース研修（データベース基礎編）【ミクシィ22新卒技術研修】