【IT】アマゾンとセールスフォース、オラクルから“サヨナラ” オープンソースのNoSQLへ移行進む
■ このスレッドは過去ログ倉庫に格納されています
米オラクルの主要顧客であるアマゾン・ドット・コムとセールスフォース・ドットコムは重要なビジネスシステムで使用するデータベースソフトについて、現行のオラクル製品に代わり、コストがより低いオープンソースのソフトへの乗り換えを積極的に進めている。情報サイト「ジ・インフォメーション」が協議に詳しい関係者の話として報じた。
報道によると、アマゾンとセールスフォースでは、オラクル製品からのソフト移行の取り組みがすでにかなり進んでいる。オラクルのデータベースソフトは世界最新鋭と広く見なされるが、競合に比べ最も高価でもあり、両社がオラクル製品を見限る理由は十二分にあると、同サイトは報じた。2日の米株式市場でオラクルの株価は一時2％下落した。
同サイトはさらに、アマゾンは2000年代の早い段階からオラクル製品に代わるソフトの採用を模索しており、その取り組みは進んでいるとした。アマゾンは巨大な電子商取引事業を支える2つの社内データベースをすでにオラクル製品からオープンソースのNoSQLに移行済みだと、移行について知る関係者2人が話したという。
セールスフォースでは、「サヨナラ」というコードネームが付いたデータベース製品切り替えプロジェクトが社内での実践段階に達したと、ジ・インフォメーションが事情を知る元従業員の話として伝えた。報道によれば、データベースは2023年までにオラクル製品から切り替わると同社は見込む。
オラクル、セールスフォース、アマゾンはそれぞれ報道に関するコメントを控えた。（ブルームバーグ）
https://www.nikkan.co.jp/articles/view/00456418 普通の会社ならオラクル使い続けるべきだよ
オープンソースは結局維持費が高い
アマゾン級になら格安維持費を提示する会社も多数だろうｹﾄﾞな ゴキチョン「何故、日本語ニカ？ 差別ニダ！ 慰安婦像を増やすにだ！！！」 彡⌒ ヾ
( ＾ω＾)SQLって、常時稼働が前提の接続技術だからなぁ
彡⌒ ヾ
( ＾ω＾)電源を切るPCには事実上使えない オープンソースでもかなり信頼性上がってるんだろうな。
昔は商用で使えるもんじゃなかったけど。 >>8
>SQLって、常時稼働が前提の接続技術
ＳＱＬが 接続技術って。。。。 >>12
彡⌒ ヾ
( ＾ω＾)Databaseとでも言えばいいのか。ハゲ もうAmazonが世界を牛耳ってるといってもいいなこりゃ。。
一気にOracle離れ進みそうだわ
そのうち日本に特化したりしてOracle >>12
彡⌒ ヾ
( ＾ω＾)シッタカして揚げ足取りする前に、自分の知識の無さを認識した方がいいぞ NoSQLは早いんだけどリレーションを使うときは不便なんだよな すまん、１０年以上前にＲＤＢ離れてから疎いんだが
NoSQL ってリレーションとは全く違うんけ？ >>4
> アマゾン級になら格安維持費を提示する会社も多数だろうｹﾄﾞな
なんで他者に頼む前提になってるんだ？
自前で維持するに決まってるだろ。 あれ、グーグルがこの分野のさきがけで独自データベースつくってたよね。
後追いか。 >>8
電源を切るPCでも使えますが
なんなら、スマホとかでも普通に使ってる >>25
彡⌒ ヾ
( ＾ω＾)あそう？としか言いようがないわ
彡⌒ ヾ
( ＾ω＾)実用的と使うとでは意味が違うからな オラクルもNvidiaみたいに一方的に強気の契約に変えたから反発が多いんだろ。 >>29
実用的だぜw
あんたがスマホ使ってるのなら、
それらの殆どはスマホで動くDatabaseを使ってるだろうよ。 >>23
他社を使うケースが多い。
昔、日本の家電メーカーがたくさんIT部門を作り、落ちぶれた後はそれを分社化したけど、いまだ重荷になってるでしょ？
という状況をご存知であれば、本業以外はやるべきではない。
ただ、あなたの言うとおり、Amazonあたりならば、Amazon自体の業態を変えながら内製しそれを維持する可能性はある。
この場合、長期的な視点では会社そのものの方向性が変わっていくだろうね。 オラクルはライセンス料上がるし毎年保守料上がるし、導入ポリシーも厳しくなってるし。
原因不明のおかしな動作も増えてるし。
嫌ってる人は多いな。 >>38
あっというまにクラウド市場ぶっちぎったもんなあ >>44
彡⌒ ヾ
( ＾ω＾)お前がシッタカの馬鹿って事は、みんなが理解できるわ
彡⌒ ヾ
( ＾ω＾)機能を知らない馬鹿が >>46
彡⌒ ヾ
( ＾ω＾)Dataの転送が早くて転送量が少なくて済む、ある意味接続技術だろうが
彡⌒ ヾ
( ＾ω＾)その前にDatabaseだと俺は言っている、馬鹿は揚げ足取りで自爆死するんだよな >>46
彡⌒ ヾ
( ＾ω＾)上辺だけで本質を知らないで物事を言うなよ、低能が Oracleから乗り換えるならNoSQL系じゃなくてAuroraかと思ったがMySQLベースなのが嫌なのか
それともAmazonにとってRDBという概念が過去のものなのかな >>48
まぁ落ち家よw
sqlのdbからnosqlの別の奴に移行した成功事例を
1>> が案内してくれるだろ? 多くのシステムはトランザクションなんて不要で
結果整合性さえあればよかったって感じか？ >>50
MySQLは本当の意味でフリーじゃないから
MySQLベースって時点で将来紛争の種になることは目に見えてる >>46
SQLは接続技術に決まってるだろ。
ハゲ足とるなよ。
これはハゲの世界では常識。 そういやシークエルって競走馬が年末あたりに走ってたな >>47
SQLは接続技術でもデータベースでも無いぞ。 オーケーオーケーいい傾向や
オラクルなんか死んでまえ たぶんCassandraかHBaseじゃねーかな
MongoDBは電子商取引事業に使うには遅すぎるし 俺らの世界ではSQLは、言語であり、また規格そのものをさす。
ハゲの世界では違うというそれだけのこと。 ハゲAAみたいに日本語下手な技術者って結構いる
ハゲが原因なのか、日本語下手だからハゲなのかは分からないが Oracleは20年以上前からボラクルとIT業界では言われていたからな NoSQLなんて出てるんだ、MySQLの亜流のMariaSQLっていうのが出たころにプログラムやめた オラクルから自由になるプロジェクトの名前が日本語のさよならなのかｗ
ワロタ Amazonみたいな通販の取引は過去データが変更される事がないのだからNoSQLの方が向いてるよな。
修正はデータを書き換えるのではなく打ち消すデータと正しいデータを追加するだけだし。 >>15
最大手製品を使わないと責任問題になるから。
別製品に変更してトラブル起きると責任問題になるから。 彡⌒ ヾ
( ＾ω＾)またシッタカ馬鹿が俺様に絡んで自爆死
彡⌒ ヾ
( ＾ω＾)バカは学習能力が無いのもうなずけるわ（爆 >>62
彡⌒ ヾ
( ＾ω＾)俺は実際の動きを説明しているぞ
彡⌒ ヾ
( ＾ω＾)俺様に絡んだシッタカの馬鹿に言ってやれ クラウドコンピューティングはアマゾン「AWS」マイクロソフト「Azure」が世界２強 >>80
あ、起きたの？おはよう。
気になってこのスレに張り付いているんだね。 >>82
彡⌒ ヾ
( ＾ω＾)シッタカ爺、おはよう！
彡⌒ ヾ
( ＾ω＾)まだ自殺しないんですかね？ アマゾンすごいなソフトウエアまで自前にするのか、一人勝ちなんて言われてるけど経営努力してる
からえらいよな。〇天とかもうやばいらしいけど納得だわな。 彡⌒ ヾ
( ＾ω＾)オープンソースはバックドアを仕込みにくい SQLは問い合わせ言語だぞ
RDBはSQLで問い合わせ可能なように実装されたDB
そのDBに色んな製品があってオラクルもその一つ オラクルは去年もAWS上で使うライセンス値上げとかやってたけど、使わざるを得ないところから限界まで搾る事しか出来ないんだろうな
段々と先細りするだろう >>54
残念ながらアマゾンもセールスフォースも日本企業に当たる企業はございません 見積を見て、客がOracle離れしていった
もう10年以上使ってないが、オープンソースでトラブったことない
障害時の解決策もOracleより簡単にみつけられるし >>85
初期からサーバソフトも自前で書いてたくらいだよ
見た目だけで本屋ガー言ってたヤツも多いけど >>85
ソフトウェアまでというか
あそこはソフトウェアが本業ですよ… Oracleのメリットは、「Oracleに問い合わせてますので」という時間稼ぎが使えること
だが「そんな戯言は聞いてない、何とかしろ」と言う上司や客には通用しない むしろAmazonがまだOracle使ってたことに驚き
内製はとっくに自社基盤使ってるのかと 犯罪はだいたい内部の犯行だから
ソースが見えない製品なんて危なくて使えないわな >>85
元々自分のところで使うシステムは自前で開発してたぞ
AWSなんかはその副産物みたいなもん 殿様オラクルは評判悪いよね、乗り換える客が多い
クラウドを演じても、しょせん20世紀のDB製品とビジネスモデルだもの
そうそう変われんよ NoSQLのくせにまだSQLは使ってるんだな。紛らわしい。 noSQLってRDBMSじゃないだろ
大丈夫なのか？ NoSQLはNot only SQLの略で、
その名の通り、SQL言語を使わずにデータの操作ができるデータベースを指します
読み取り一貫性とか保障されるの？ >>90
Not Only SQL の略じゃなかったっけ？ nosqlでオラクルのリプレースができるか？できないね。 単に永続的な記憶域が欲しいだけでKVSで十分なことも多いんだよね Oracle製品を仮想化基盤上で動かすときのライセンス条件がとても(コスト的に)厳しくて
仮想化やめますか？
Oracleやめますか？
ってレベル NoSQLは簡単に言えばkey value storeのこと
insert(key, val) と思えばいい
トランザクションとかはない 高い物には、それなりの理由と良さがあるもんだよ
5ｃｈみたく安ければ何でもいいって言ってるうちに顧客リストが流出する >>119
トランザクション無しで在庫管理とか大丈夫なのか？
NoSQLの軽快さを維持してそこをクリアするのがシステムの価値になるのかもしれないけど。 >>121
Google Chrome はトランザクション無しの軽さを武器にＦｉｒｅＦｏｘを撃墜したしね ノーsql、ノーリレーショナルの概念がよくわからない。
あと、webデータベース時代になって
1行型の設計がやたら推奨されているが
伝票や受注などの親子雛形に慣れているので
頭を切り替えるのが大変。 Webサービス系のエンジニアだけど新規の案件はSQL型のデータベースではなくAWSのDynamoDBを採用することもでてきたよ
ものすごくクセがあって無理なことは多いけどLambda と相性が良くて簡単なことはあっという間に作れるかな
コストも安いし >>8
何この低スペコテハン
sqlが接続技術？
まともな知識持ってればそういう言い回ししないだろ
これは揚げ足取りじゃなくて、お前知ったかしてて実は何も分かってないだろっていう突っ込み >>4
根本的にずれている
お前のカツラのように
老害 そもそもAmazonには
各種データベースのオープンソースにコミットしてるエンジニアもいるのに笑
維持費とかあんまり笑わせんなよ。
後進国の老害の発想 >>100
それでやってきたOracle担当が
「ＸＸＸＸＸ！ＸＸＸＸＸＸ！！！ＸＸＸ．」
という全く解決方向に話が進む答えでは無い事を堂々と言うからな
一次受の○Ｅ○とその下の○○Ｅの担当があきれ果てた案件思い出した CPU性能あがってんだからDBの差なんて関係ないわな今や
オープンソースで十分 以下、俺の推測ね。
amazonは、AWSで柱が出来たから次を考えている
AWS並に実績が伴った、且つAWSには向いていない用途のサービスをやりたい。
ということでビッグデータの扱いに「向いていると言われている」NoSQLを
用いたamazon上で稼働させ、箔を付けた上で、
AWSと双璧を成すサービスを提供して、他のライバルを駆逐したいのだろう。
別に、NoSQLがamaoznのショッピングサイトの運用に向いているとか向いていないとか
そんなのはどうでもいい。
そもそもamaoznの新運用で多少転けたとしても、
他のライバルは全くamazonにかなわないのだろう？
一位を独走している今だからこそ出来る技だと思うがね。 >>130
失笑。
5年くらい前の発想。
そんなステージはとうに過ぎている 色々ずれまくったこと言ってるから
それくらい認識した方がいいよ。 >>119
トランザクション処理してないって
業務に使えないじゃん
銀行系とか販売系とか
トラン、ロールバック処理とか
どーすんだ？ 列指向データベースとは
列指向データベースは、データ行ではなく、データ列の読み書きに最適化されています。
データベーステーブルの列指向ストレージは、総ディスク I/O の要件が大幅に緩和され、
ディスクからロードする必要のあるデータ量が減少することから、
分析クエリのパフォーマンスにおいて重要な要因になります。
なるほど分からんｗ >>136
少し頭使えばいいだけ。
トランザクション実装するには一番おもしろい所じゃん。
しかしやっぱり科学力が無い人は無理がある。 非リレーショナル (NoSQL) データベースは、通常、スキーマを必要としません。
値、列セット、半構造化 JSON、XML、または関連する項目属性を含む
その他のドキュメントの取得には、通常パーティションキーが使用されます。
パーティション・キー
プライマリ・キーの定義で最初に宣言されたカラム。または、複合キーの場合は、
複数のカラムが、プライマリ・キーを形成するこれらのカラムを宣言できます。
スキーマ
スキーマ（schema）とは、データベースの構造であり、
データベース管理システム (DBMS) でサポートされている形式言語で記述される。
関係データベースでは、スキーマは関係 (表) と関係内の属性 (フィールド) 、属性や関係の関連の定義である。
さっぱり分からないｗ カラム ［1］ 【column】
表形式のデータで，縦の列。 NoSQLを理解できない人は、SQLも本質的には理解できていない知ったかぶりの人
片方を理解できるだけの知能がある人はもう片方も理解できる トランザクション処理できないNOSQLって
銀行系とか医療系とか証券系とか
信頼性が絶対条件の業務には適用できない
「完全に置き換え」なんて有り得んよ 問い合わせが得意だから
大量のスループットが要求されるクエリに適用されるんだろうな
Amaのダイナモのように
銀行系とか読み取り一貫性が絶対条件のDBは
今まで通り、堅牢なリレーショナルDBしか有り得ん >>11
君がいつのことを言っているのか知らないが、postgresqlやMySQL は昔から高性能だったよ。
そして、全く役に立たない国産DBなんて今は影も形もない。
どっちが有能で有益だったのかは結果を見れば明らか。 >>21
なんでNoSQL選んでるのにリレーションなんて使いたがるんだ？
KVSでいくらでも必要な数値をかまえるだろう？ >>22
リレーション使って、クエリ作ろうとすると、一度クエリ展開しないと処理が続かない。
でもクエリの展開は分散処理が難しい。
最初から元になるクエリを予想して、その表に必要な値を組み込んでおけば、例えばキーとなるidで分割して分散処理ができる。
そういう工夫をしたデータベースをNoSQLという。
まあ、使いにくいんで、現実には上位からはSQLを使っているように見えるラッパーかけとくことが多い。 >>26
はあ？
君はキーバリュータイプのNoSQLしか知らないのかい？
どれだけ馬鹿なの？ >>25
はあ？
君のスマホは電源切らないの？
じゃあ、メンテナンスの時は困ってしまうね？ >>32
君はなんで何も知らないのにだれも得しない、君の妄想を垂れ流そうと思ったの？
君が君のことを馬鹿だと理解できないのは良いけど、馬鹿がスレ流しするのはうざいんだけど？ >>143
NoSQLの大半はトランザクション処理ができる。
というより実務で実際日本の銀行全部の処理よりも過大な処理に使ってる。
何言ってんだこの馬鹿は。 まるで10年前の世界にいるかのようだ。
これが日本か。呆れて物も言えないレベル。 >>143
完全に置き換えるとは誰も言っておらず適材適所
むしろそれを理解できずリレーショナルデータベースのみ用いて非効率なシステムにしてしまうところも多い >>154
そもそも、NoSQLを使ったトランザクションが必要な国内の業務ってなんすかね？ >>143
nosqlで銀行系とか導入できるワケないよな
速攻で門前払いだぞ
rdbmsはこれからも絶対になくならないよ >>156
門前払いする必要もないし、まともにビックデータ扱うならSQLにはボトルネックがあるんだから逆立ちしたって扱えやしない。
でも、問題は今の日本の銀行にビックデータを取り扱う必要があるか。
数百万件程度の処理ができなかったみずほに別にペナルティあったわけじゃないからね。
客をどこまでも待たせて不便な扱いできるような業界にビックデータはいらない。 >>125
彡⌒ ヾ
( ＾ω＾)またシッタカの馬鹿が現れた >>145
彡⌒ ヾ
( ＾ω＾)知的障害者、おつ 彡⌒ ヾ
( ＾ω＾)ほんと上辺だけシッタカして、本質を知らん馬鹿が多い事
彡⌒ ヾ
( ＾ω＾)日本が終わっている事の象徴だな >>159
お前かよ。
SQLはデータベース言語であって接続技術じゃないぞ。
まだわからないらしいな。
無様だな。 >>160
SQLのLが言語のことだってのは中学生でもわかる話なんだけどな？
表面的？
お前は表面すらわからない。 >>161
彡⌒ ヾ
( ＾ω＾)データ転送技術と言えばいいのか？馬鹿 彡⌒ ヾ
( ＾ω＾)俺が居ない間にネットで調べて必死で反論を見つけております！！
彡⌒ ヾ
( ＾ω＾)バカの必死の抵抗です！ >>156-157
おいおい、BankVision知らんのか。
勘定系にSQLサーバー組みこんだシステムは
アメリカじゃ普通だし、SQLが勘定系で使えないとか
10年前の常識だぞ。 彡⌒ ヾ
( ＾ω＾)まるまる24時間かけて調べて反論してくるなんて
彡⌒ ヾ
( ＾ω＾)もう本当に勘弁してくれよ >>166
みんな引き篭もりなんだよ 勘弁してやりなよ アマゾネス、オラクル
原始宗教っぽくてぴったりじゃないか。 AWSのEC2で（Oracle社の）MySQLを使ってるんだが、
例のIntelのパッチが当たって以降、性能が劣化してる
そんなところにこのニュース…… >>166
( ＾ω＾)SQLって、常時稼働が前提の接続技術だからなぁ
( ＾ω＾)電源を切るPCには事実上使えない
使える使えるぞ。windowsネイティブの単体プログラムで
SQL-DBを使ったプログラムはたくさんあるよ。
俺はMySQLとか使ってる。 >>170
彡⌒ ヾ
( ＾ω＾)詳しい事を忘れたんだが
彡⌒ ヾ
( ＾ω＾)不整合みたいのが起こりやすいイメージが有る
彡⌒ ヾ
( ＾ω＾)作り方次第だろと言われてしまえばそれまでなので、反論はしない NoSQLには大きく分けて4種類ある
1.KVS 2.ワイドカラム 3.ドキュメント志向 4.グラフDB
それぞれ特性が全然違うので注意な >>163
SQL はデータ転送技術じゃないな。
バカはいつになっても自分の間違いを認めることができない。
だからいつまでたってもバカのまま。
恥ずかしいねー、愚かだねー。 >>175
彡⌒ ヾ
( ＾ω＾)もうシッタカは死ねよ
彡⌒ ヾ
( ＾ω＾)馬鹿ほどしつこい アマゾンとセントフォースに見えた
フリーの女子アナが何すんのかと >>165
何を言ってるんだか
勘定系にSQLサーバー組みこんだシステム
ってことはRDBMSが現役バリバリってコトだろ
NOSQLなんて問い合わせにしか使えんよ
ビックデータの分析には最適だがな >>109
♪ノットォ〜オンリィ〜
バットォ〜オルソォ〜 オラクルは独自仕様が多く、それだけならまだしも標準SQLが通らないことすらある
ライセンス料も高く保守料金も高い、突然ライセンス形式変更によって最新バージョンへのアップグレードの道が断たれることもある
はっきり言って、使いたくない >>156
あなたの言っていることは正しい。
ただし今までRDBMSを使っていた、銀行系とか証券系とかmsec以下でのリアルタイム在庫管理とかじゃない99％のシステムは、RDBMSである必要はない。
特にクラウドサービスになるとNoSQLのレスポンス性能に、RDBMSはとても太刀打ちできない。 DBサービスがSaaS化、PaaS化する中で、Oracleを買収するのはどこかという段階に移りつつある。
AmazonやGoogleは今更OracleレベルのDB技術を欲しがらないだろうし、MS、IBMはそもそもOracle対抗のDBMSを持っている。
SAPやSalesforceのような企業がもう少し伸びてOracleを飲み込む日が来るかもしれない。 >>4
Oracleのぼったくり価格にはどこの会社もうんざり。
しかも、AWS等のクラウド利用は禁止されていてOracle Cloud使えと言い張る。
そんなゴミな企業はつぶれてしまえと思うわ >>184
結果整合性のあるシステムを設計できるエンジニアは少ないからな
強い一貫性は性能落ちるけど、不整合時のコストがないから比較的設計も楽 日立「えー！？ボラクル！？うざーい！いまどきボラクルにこだわってるのは官公庁だけだよね！キャハハ！」 主要OSSデータベース、インメモリDB、KVS
Apache Derby
Firebird
MariaDB
MySQL
PostgreSQL
SQLite
memcached
MongoDB
Riak
VoltDB
Apache Cassandra
Apache HBase
infinispan
Redis
Neo4j ＯＬＴＰ用（トランザクション処理）とＯＬＡＰ用（データ分析）
ＳＡＰ ＨＡＮＡみたいなインメモリＤＢが増えてくれば、両方を１つのＤＢＭＳでできるようになるな >>171
日経なんとかで聞きかじった知識だけで生きてるからそうなる >>150
何を勘違いしたらそんなレスになるんだ。。
> 君のスマホは電源切らないの？
> じゃあ、メンテナンスの時は困ってしまうね？
スマホって知ってる？ >>192
彡⌒ ヾ
( ＾ω＾)お前がシッタカで関わった事が無いトーシロって判ってんだよ
彡⌒ ヾ
( ＾ω＾)あまりにも馬鹿な内容のレスでな
彡⌒ ヾ
( ＾ω＾)さっさと死ねよ、キチガイ >>188
単なる連番をキーにしてずらずらと100以上の項目が連なるテーブルとかざらにあるよなー ロボコップのラストで「sayonara!robocop」って言ってたのを思い出した。 そうか！
SQLで書けばTCPも使えちゃうんだね。すごいや。 >>176
このバカはSQLは接続技術だと言って、大笑いされたのに未だに、接続技術だと言い続けています。
そのくせ自分は技術わかってるつもりなんだから迷惑だよな。 >>193
横から何勘違いして書き込みしてんだ？
それともお前はこのバカ本人か？
電源を切るPC何てアホしか使わない表現よく思いつくよな。
お前はどうなんだ？電源を切るPCに役立つ技術の支援者か？ >>195
糖質はお前。
SQLでIPの割り当てとかどうやってやるの？
通信速度のネゴシエーションとかするの？ >>201
> 電源を切るPC何てアホしか使わない表現よく思いつくよな。
なんかよくわからんけど、>>8に言ってくれ。 >>200
彡⌒ ヾ
( ＾ω＾)まーーーーだシッタカしてドヤ顔してやがる
彡⌒ ヾ
( ＾ω＾)お前が一切知らんのは解かっているんだよ
彡⌒ ヾ
( ＾ω＾)なんでこんな馬鹿が生きているのか分らん
彡⌒ ヾ
( ＾ω＾)今日にでも死んだら？ >>204
彡⌒ ヾ
( ＾ω＾)もうグダグダなのに無理に絡むなよ、バカ過ぎて話にもならん >>185
SAPはSYBASE買ったからERPのためにDB自前で作ってるぞ >>207
その割にはSAP内部で動くRDBMSはOracleの場合が多いんだよな。 noSQLだと技術のないデータベース土方が死ぬからせめてポスグレにしてくれ >>206
だから、文句があるなら>>201に言ってくれ。
バカ同士の議論に俺を絡めるな。 >>3
日本語のサヨナラは 別れ 散る 死ぬ
粋にも聞こえんな。 >>1
ほんとかよオラクルの株売ってくる
今日からNoSQL使うわ まぁオラクルは日本を捨てたからな
強制2ライセンスってあほかと
同価格で買えるならともかく2倍ではなくサポート込みで3倍近いからな
舐めすぎにもほどがある >>208
ユーザの要望だろw
でも2024年くらいでサポート終わりになるから自社製に切り替えといってるはず CONNECT FROM Hage
WHERE Port = 5432
AND Protocol = 'tcp';
出来るな。 >>217
それSQLじゃない。
Connect文はSQLにはない。 >>211-212
彡⌒ ヾ
( ＾ω＾)SQLを使った事が無い低能シッタカが必死でシッタカ
彡⌒ ヾ
( ＾ω＾)社会の落ちこぼれは哀れ過ぎるわ
彡⌒ ヾ
( ＾ω＾)ＥＶ馬鹿と完全に同じ postgresqlに変えたら6倍以上速くなりました。
しかもコストは1/10。 >>171
お前もしかしてPTを指して常時接続とか
不整合みたいなのが起こりやすいとか
言ってるんじゃないだろうな？
だとしたら理解力なさすぎだぞ？ >>222
彡⌒ ヾ
( ＾ω＾)で、また24時間かけて必死で粗探しのネタを探して、その程度の反論か？
彡⌒ ヾ
( ＾ω＾)どこまで底辺なんだよ >>223
は？すでにPTの話題はこのスレで出てるが？
お前まさかPT知らんのか？ >>225
彡⌒ ヾ
( ＾ω＾)シッタカ馬鹿の典型 >>227
彡⌒ ヾ
( ＾ω＾)糖質は俺様に絡んでんじゃねーぞ、バカのくせしてしつこいんだよ >>229
彡⌒ ヾ
( ＾ω＾)シッタカ馬鹿 「もう黙ってろよ」
彡⌒ ヾ
( ＾ω＾)馬鹿なので24時間調べて必死で反論（爆 >>230
「で、また24時間かけて必死で粗探しのネタを探して、その程度の反論か？」
24時間以上前に出てる話なのにこんなレスする白痴がよく言うわ >>231
彡⌒ ヾ
( ＾ω＾)シッタカ馬鹿 「もう黙ってろよ」
彡⌒ ヾ
( ＾ω＾)馬鹿なので24時間調べて必死で反論（爆 彡⌒ ヾ
( ＾ω＾)本質を知らん馬鹿は、揚げ足取りしかできん低能の馬鹿 >>232>>233
まともにレスもよこせんのか
まあ最初からまともなレスなんてできんだろうが
勝手に自爆して揚げ足取りとか言ってる低能 >>234
彡⌒ ヾ
( ＾ω＾)本質を知らん馬鹿は、揚げ足取りしかできん低能の馬鹿 >>234
彡⌒ ヾ
( ＾ω＾)上辺だけのシッタカは世の中怖いもの無しだな（爆 >>235
PTとかDBの本質だろうが
SQLだろうがNoSQLだろうが根幹だろ
まじで知らんのか >>237
彡⌒ ヾ
( ＾ω＾)上辺だけのシッタカは世の中怖いもの無しだな（爆 >>238
上辺とか何いってんだかもう白痴は黙ってろよ >>240
彡⌒ ヾ
( ＾ω＾)上辺だけのシッタカは世の中怖いもの無しだな（爆 >>242
mysqlなんてフリーなんて言ってもいつオラクルが
手のひら返すか分からんから使いたくないんだよ
H.264やJavaでGoogleは痛い目見てるから AmazonでNoSQL言ったらDynamoに全力投資していくって事だろ？
うちが高速化とエンジニア負担の軽減のためにRDS使うような新規プロジェクトは全てDynamoで検討し始めているからな
問題は設計だな、SQLで出来る機能は全てNoSQLで出来る訳じゃ無いけど、そこを突破しないといけないから
発表したって事は見通しが出来たって事だけど >>218
ネタに決まってんだろ、、、
はぁ、このスレのレベルじゃ伝わらないのか
ハゲと大して変わらんな。 なんでDynamoDBにこだわるのか。
適材適所という概念のないアホなんだろうな。
どいつもこいつも
とりあえず使ってみようみたいなアホばかり。 そのうち、パーティションで泣きを見るんだな。こういうのが。 >>249
俺はたまにいるS3推しするエライ人の考えが理解できないな
S3の仕様からすると、あれは凍結するデータにはとてもいいけど、生きているデータ向けでは無いよ
引っ張り出す必要があるデータにS3を使うとか性能面でもコスト面でもあり得ないんだけど
信頼性確保の為に必須という点ではそうだけど、その為に用いるならS3とRDSでデータ不整合を起こしていないかどうかをチェックする為の設計も入れないといけなくなるし、
予算も期間も少ないこの時代では不安材料を抱えたままリリースする事になる
性能を無視していいんならいいんだけどもさ、性能の良し悪しはコストに直結するから、俺はS3を積極的には利用しないな >>250
ec2使うならイケると思った俺が甘かったわ
dynamoは使おうと考えたことないけど死ぬことはないのか？ >>251
Dynamoは性能を金で買う仕組みだから、金さえ積めば性能面で死ぬ事はないし、
逆にアプリケーションのデータ通信仕様が決まっていればコストは見積もりやすいし、
通信量が増えた時の対応がポチっとすればいいだけなので楽
高いけどね >>196
最近多いな。その連番も自動生成だし
つか、そんなのならNOSQLでいいよってことなのかもね >>36 い・・・いや・・・JARL切れてるんでNoSQLで・・・（違 オラクルって高くて高機能だけど、別に速くはないよね。
バグも多いし。
ユーザーの多いオープンソースの方が早いうちに致命的なバグが直っててよい >>256
Githubでissueあげれば必要なら対応してくれるしな。 >>258 でもこの時期のGithubはメルトダウン機能埋め込まれそうで怖くね？ >>256
カリカリにチューニングしたオラクルは早い。
PostgreSQLは同レベルのチューニングはできない。
まあ、用途が違うからな。
MySQLは適切な設定でチューニングすれば早いが、そのレベルのチューニングができるエンジニアは多くない。 >>256
だからmySQL買ってライバル減らそうとしたんやで >>1
>アマゾンは巨大な電子商取引事業を支える2つの社内データベースを
>すでにオラクル製品からオープンソースのNoSQLに移行済み
このスレではごちゃまぜに話されてるけど、これは、AWSには関係
無いアマゾン内部の社内利用の話だな。
しかもRDMSが全てNoSQLに全て変わられるなんて、用途からすれば
あり得ない話。
AWSは単なるサービスだから、関係するとしたらNoSQLのサービス
が出来るだけだろ。
MySQLだろうが、SQLServerだろうが、オラクルだろうが提供する。
この記事は、オラクルが排除されるみたいな書き方がおかしい。
単にオラクルの株価を落としたかっただけじゃ無いのか。
まあ、アマゾンの社内利用だけでも相当の金をオラクルには払ってる
んだろうけど。 >>262
バカは何もわからないのね。
そもそも何でNoSQLを使うと思う？
SQLの方が遥かに簡単で、コストが低くて、正しい結果を返すよ。
AMAZONはNoSQLのためのサービスなんて立ち上げる予定はないし、そんなことに投資する意味がないんだよ。
本当にバカは自分の狭い狭い所でしかものを考えられない。 >>264
で？
馬鹿はアマゾンが開発したデータベースの名前を知ってれば偉いと思ってる。
馬鹿は馬鹿だよね。 >>266
根本的な知識が足らなくて恥ずかしい書き込みするやつよりは偉い。 >>268
話についたこれない馬鹿の癖に必死だな。
どこが知識がないか説明もできないじゃないか？
馬鹿は馬鹿。結局自分の行動で自分が馬鹿だと証明してしまう。 Dynamoも知らんくせにしゃしゃり出てきて語るとかウーマン村本かよｗｗｗ 「NoSQLは正しい結果を返さない！」（ｷﾘｯ
って人は自分が遅れていることを自覚したほうがいいよ SQLは接続技術じゃない
接続なんかはまるでない単体アプリ内で使うことも可能
問い合わせ言語仕様ですよ 接続技術ってソフトウェア界隈じゃ聞き慣れない言葉だと思うんだが、具体的になんなんだろう？ SQLってStandard Query Languageの略じゃないの？ >>271
>>272
>>273
恥ずかしいから、少しは勉強してね。
NoSQLがコンプリートな結果を返さないのは常識だから。 >>277
いや、今はSQLと言う名の技術。
その略称はIBMの社内の技術だった時に使われていた。 >>276
L2L3とかのプロトコルとか、ハード技術とかじゃないの？ >>282
頭悪いのはお前だよ。
多分お前データベースしっかり勉強してないだろ？ >>279
コンプリート？もしかしてCoherencyとかConsistencyの事を言ってる？
俺はその言い回し聞いたことないなぁ >>283
じゃあ英語版wikipediaの一文目でも書き換えてきたらw
自称情強さんよ
SQL使って利用できるサービスを支える技術を全部SQLと呼ぶみたいなおろそかな頭なんだろうけど >>284
relational completeって言葉はrelational algebraにあるけどな
query languageに関する概念
>>279の話しぶりでは
その事を言ってるようじゃないみたいだけど >>263
NoSQLの方が遥かに簡単で、コストが低くて、速くて、効率が良いから使われているのですよ
もちろん適材適所ですから効率が悪くてもSQLを使うべきところもあります
使い分け出来ずに、オラクル依存とか、SQLしか使えないとか、そういう人や会社は確実にダメなところです nosqlなんてって名前付けるから
>>280みたいな事言う奴が出てくるんだねえ >>279
>NoSQLがコンプリートな結果を返さないのは常識だから。
これ意味わかるやついる？
コンプリートって何？
曖昧な表現で知ったかしてるの？
知ってるなら正しい用語で説明してみろよ。 当然の帰結（笑）
オラクル何様のつもりなんだよ、ってやり方が嫌われたな。 >>4
そう言ってオラクルは値上げ断行すんだよな（笑）
だから嫌い >>289に答えられないようなので
>>279は知ったかクソ野郎と判断しますね。 SQL vs NoSQLって標語が悪かったんだよなあ
実質はRDBMS vs lighter othersだったんだけど 分散アーキテクチャーかどうかだろ。
ユーザーインターフェースがSQLかどうかなんてあんまり関係ない。 北米で受けたオラクルの面接官がイタリア系だったが
挨拶もしない無愛想で無礼で傲慢な豚だったが
AIで今の仕事がなくなる云々と話をしたら
「そういう世界を作ろうとしてるだ（キリ」と馬鹿笑いをしてた くだらない事はもうやめよう！
やめよう梅毒ゲイ真似拡散奴隷！
人類黄金の時代へ！ cassandra使って現在進行形で死にかけてるわ ■ このスレッドは過去ログ倉庫に格納されています
