なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか? これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま
竈門禰󠄀豆子をMySQL5.6のテーブルにinsertしようとすると正しく格納できず、竈門禰となってしまうケースがあるという話を聞き、調べてみました。 実践 まずは試しにやってみます。 mysql> show create table verification\G *************************** 1. row *************************** Table: verification Create Table: CREATE TABLE `verification` ( `name` varchar(100) COLLATE utf8_bin DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin 1 row in set (0.01 sec) mysql> inse
「Redash Meetup v8.0.0」の資料一覧です。
Amazon Redshift 新しい圧縮エンコーディング『AZ64』とLZO、ZSTDの徹底比較 これまでは主に高速なLZO、高圧縮なZSTDの2つ圧縮エンコーディングをノードタイプやワークロードに応じて選択していましたが、新たに追加されたAZ64は高速と高圧縮な特性を兼ね備えています。今回は新たに追加されたAZ64について検証したいと思います。 Amazon Redshift が最適化されたストレージと高クエリパフォーマンス向けの新しい圧縮エンコーディングである AZ64 をリリース 以下、本文の抜粋です。 高い圧縮率と改善されたクエリパフォーマンスの達成を目的として設計された独自の圧縮エンコーディングである AZ64 が利用可能になりました。革新的な AZ64 アルゴリズムは、データ値の小さなグループを効率的に圧縮し、SIMD 命令を活用してデータを並列処理します。このエンコード
タイトル通りで本当これだけなのですがv8で「先週」や「直近7日」など相対的な日付パラメータを設定できるようになりました 個人的にとても良い! Redashを入れていろんな人に使ってもらいだすとほぼ言われるであろう 「期間指定で今週とか今月とかってできないの?」という感じのやつ v8以前は対応してなかったのでパワープレイで頑張るという方法もあるものの SQLで頑張る デフォルト値でパラメータを受け取っていない場合に「直近○日」というようなクエリを書く クエリID指定で定期的にSQLで上書き(self-hostedの場合に限る) queries.optionsの中身を毎日cronで更新する などの方法が取れるにはとれますが どれも「うーん…」といった感じでした 画面 適用されるのは日付系の指定すべて 指定可能なパラメータの場合Inputの横に雷のマークが表示されクリックするとリストが出てくるの
久しぶりにペラペラな思いつきを書き捨てて、寝ます。 2、3年前ぐらいにSIerやコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。 AWSのReadshiftしかり。 なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。 Treasure Dataは基本的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。 Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変って
redash のデータベースに接続する次のコマンドで接続します。 sudo -u redash psql -d redash 接続を切るときには次のコマンド。 \q redash のデータベース容量を確認するselect t1.datname AS db_name, pg_size_pretty(pg_database_size(t1.datname)) as db_size from pg_database t1 where t1.datname = 'redash' サーバーのディスク空き容量を確認するバックアップをする前にサーバーのディスクの空き容量を確認します。 df -hT データベースのバックアップコマンドバックアップをします。 sudo -u redash pg_dump redash | gzip > redash_backup.gz バックアップコマンド
小ネタです。 Amazon Redshiftのメンテナンスアップデートにて、You can now use the ALTER TABLE command to increase the size of VARCHAR columns.(ALTER TABLEコマンドを使用してVARCHAR列のサイズを増やすことが出来るようになります)というものがありましたので試してみました。 AWS Developer Forums: Amazon Redshift Maintenance (February 20th - March 21st 2019) なお、検証は管理コンソールにて現時点でのクラスタ最新バージョンにアップグレードを行った上で行っています。 コマンド1つでVARCHAR型の桁数定義を変更(増分)可能に 検証用に、簡易ではありますが以下テーブルを用意しました。 $ CREATE TAB
Amazon Redshift で、VACUUM DELETE オペレーションが自動実行されるようになりました。これにより、それまでの UPDATE および DELETE オペレーションで削除マークが付けられていた行により占有されていたディスク空間が返却されます。また、テーブルのデフラグが実行されるため、断片化で消費されていた空間が解放され、ワークロードのパフォーマンスが向上します。 VACUUM DELETE の実行スケジュールは、クエリ負荷とテーブル内の削除済み行数に基づいて設定されます。例えば、ユーザーやクエリへの影響を抑えるため、負荷の高い期間には VACUUM DELETE の実行頻度が下がります。VACUUM DELETE の実行は、入力されたクエリの負荷が高いときには自動的に一時停止し、しばらくたってから再開されます。Amazon Redshift ではバキューム処理が不要な
はじめに 2015年05月11日にAmazon Redshift の Interleaved Sorting機能のリリースが発表されました。 データ分析では複数の分析軸によるデータディスカバリーが求められますので、DWHは高速に異なるカラムの検索や集計が必要とされます。既存のソートキー(COMPOUND SORTKEY)は、ソートキーの定義に無いカラムでは全てのブロックのスキャンが発生するので相対的に早くないという課題がありました。今回の Interleaved Sortingのリリースによって、ソートキーに指定した複数のカラムに対して、クエリーのフィルタを柔軟かつ高速に行えるようになりました。 昨年のre:invent2014のSDD414 - Amazon Redshift Deep Dive and What’s Next の "Multidementional indexing w
日本時間の2018年11月16日、下記ツイートにありますようにAmazon Redshiftにて『Elastic Resize』なる機能・仕組みが新たに導入されました。 Today's #AWSLaunches! 3/5 ⭐ AWS Cost & Usage Reports add Athena integration, Apache Parquet Output & Report Overwrite ⭐ Amazon Redshift announces Elastic resize, so you can add & remove nodes in minuteshttps://t.co/r8ekyCt1bR pic.twitter.com/6469grjiY4 — Amazon Web Services (@awscloud) 2018年11月16日 Amazon Redshift
概要 ところでこのツイートを見てほしい。このソースコードをどう思う? 世界最悪のログイン処理コード。 実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn — はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日 すごく……セキュリティーホールです…… 一応は動いていますが、あまりに問題がありすぎるため、Twitterでも話題になっていました。 問題点は片手に入り切らないぐらいある気がしますが、一つづつ解説していきます。 ※元記事のタイトルに記載されていますが、このコードはイントラネット内で動作していたものです。 問題点リスト 1. クライアント上のJavaScriptで書かれている 他の問題点を全部ぶっ飛ばすぐらいの重大な不具合です。 クライアントと言うのはこの場合、
I need to stay awake and fate go doesn't work APOLOGEMS pic.twitter.com/vvCcrmBkbn — Jose (@Neko_Jose) 2017年12月20日 Looks like it’ll be a while before I can play again. I don’t care too much about how many apologems they give out, as long as everyone can play without fear. pic.twitter.com/fclQqtnJWu — SULLEN (サレン) is Getting Coal for Christmas (@sullenswordsman) 2017年12月20日
MySQL、CakePHPで「tinyint(1)」のフィールドは Boolean型として認識 MySQLでの「tinyint(1)」のフィールドは Boolean型と認識するが... MySQLの「tinyint(1)」の悲劇 Boolean型になるとは... この記事に「結論が間違っています」コメントをいただきました。 そのために検証を行った結果、「tinyint(1)」のフィールドが「Boolean型」として処理されるのは MySQLの機能ではなく、CakePHPの機能によって起こっていることを確認しました。 ※厳密な表現では、MySQLでは「tinyint(1)」で設定されたフィールドは Boolean型として処理する仕様となっているため、その定義に従って、CakePHPでは「0」「1」しか持てないように処理している、ということになるでしょう。 MySQLの定義については以下参照
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く