常連

サーバの勉強をし始め、データを管理するにはMongoDBやMySQLのような組み込みの機能を使うのが一般的だと最近知ったのですが、これらを商用で利用する場合のライセンスはどうなっているのでしょうか

いくつかサイトを見てみたのですが、これって黙って商用に使っていいのでしょうか・・・


http://anond.hatelabo.jp/20140722001658
http://www.mongodb.jp/mongo/licence

補足：
function(){
//MongoDB内を検索する処理
}
とゆうMongoDBのファイルに関与する関数が有るとします。

例えばアプリケーション（クライアント所有アプリ）から、サーバ内のMongoDBを呼び出す際に
サーバ側に上の関数を配置するのはOKだけど、
クライアントアプリ内に直接上記関数を入れるのはNG

とゆう解釈でしょうか？

データベースのライセンスについて

データベース & DynamoDB 初学者です。

DynamoDB のトランザクションについて勉強中に、トランザクションと別トランザクションの衝突、もしくはトランザクションと PutItem などのリクエストの衝突が発生した際の挙動についての自分の理解が間違っていないか不安で質問させていただきました。
  


### 自分の理解

以下の形式で書かせていただきます
- トランザクションの衝突のケース
    → その際の挙動に対する自分の理解

- とある項目に対する PutItem、UpdateItem、または DeleteItem リクエストが、同じ項目を含む実行中のトランザクション (TransactWriteItems) と衝突した場合
    → DynamoDB のトランザクションはロックを取得しないため、トランザクション処理完了前に他の PutItem などのリクエストによって対象項目が更新される可能性がある。その場合、トランザクションは失敗する。


- 同じ項目に対する TransactWriteItems 同士が衝突
    → どちらのトランザクションもロックを取得しないため、どちらのトランザクションも項目の操作はできる。先に処理が完了した方のトランザクションが成功し、後のトランザクションは失敗する


- とある項目に対する PutItem、UpdateItem、または DeleteItem リクエストが、同じ項目を含む実行中のトランザクション (TransactGetItems) と衝突した場合
    → DynamoDB のトランザクションはロックを取得しないため、トランザクション処理完了前に他の PutItem などのリクエストによって対象項目が更新される可能性がある。その場合、トランザクションは失敗する


- 同じ項目に対する TransactGetItems 同士が衝突した場合
    → 先に処理が完了した方のトランザクションが成功し、後のトランザクションは失敗する (?)


- 同じ項目に対してトランザクションA (TransactGetItems) とトランザクションB (TransactWriteItems) と衝突した場合
    → 先に処理が完了した方のトランザクションが成功し、後のトランザクションは失敗する (?)


上記の理解のうち間違っているところがございましたらご指摘いただけますと幸いです。


### 調べたサイト

[トランザクション競合の処理(公式ドキュメント)](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/transaction-apis.html#transaction-conflict-handling)

[New – Amazon DynamoDB Transactions](https://aws.amazon.com/jp/blogs/aws/new-amazon-dynamodb-transactions/)


### 最後に
TeratilのようなQ&Aサイトに初めて質問をポストするので拙い文章で大変お手数をおかけいたします。DynamoDBのトランザクションについてご教示いただけますと大変幸いです。何卒よろしくお願いいたします。

DynamoDBでトランザクションが衝突した場合の挙動について

現在、社内で利用しているシステムがあります。
そのシステムのデータベースは、MySQL 5.6系を利用しています。

マスターデータを、更新される度に履歴を残していきたいと考えているのですが、
更新頻度が非常に多く、更新履歴をMongoDBへ格納しようと検討しております。

更新履歴として保存するデータは、更新前のデータ保存していく予定で考えております。
更新前データをMongoDBへ格納し、更新後のデータは、MySQLで管理し、
差分を調べたいときは、プログラム上で、判定を行いたいと考えております。

MongoDBの選定理由については、Json形式でデータを保持し、操作も容易にできそうなため選定しました。
MySQLでも、JSONの格納はできることは理解していますが、今回、NoSQLを試したいと思い試作として導入してみようと考えております。

ご教示頂きたいこととしまして、変更履歴について、皆様はどのようにデータを持たれているのか、
教えて頂きたく質問させて頂きました。

要件により履歴の内容も違うと思いますが、「どの箇所が変更されたかをあとから明確にすること」を
目的として、履歴を残していきたいと思っています。

NoSQLに、変更前、変更後を保持するのか、変更前を保持するのか、
色々な意見を頂けると幸いです。

ざっくりとした質問で申し訳ございませんが、よろしくお願いします。

データベース設計(変更履歴について)

MongoDBのメリット、デメリットについては調べて概要は把握できました。


> MongoDBにはトランザクションと排他制御がない。
> MongoDBはテーブルのJOINとかできない。
> MongoDBはRDBじゃないので集合ベースの思考が向かない。
> Cassandraは列のカウントアップもできない。MonogoDBができないかはわからない。
> MongoDBはRDBMSと違って、最初から型や制約を定義することがない。だからエンティティに属>性を増やすたびにALTER文を発行する必要がない。つまり、頻繁にテーブル定義を変えたくなる場合に作業が楽。

以下のブログより引用
http://d.hatena.ne.jp/psappho/20111030/1320055924


しかし、私がこれまで携わってきた案件では、リリース後にあまりカラムを変更したり、追加することがなかったです。（実務経験が少ないのと、要件定義がかっちりしているのが原因かとも思いますが）

そのため、MongoDBをはじめ、NoSQLのメリットが魅力に感じません。

とはいえど、ここまで注目されているということは、他社の案件では、
頻繁にカラムを変更、追加したりする需要が高いのかなと思いました。

もし、皆様が携わっている案件でそういった事例がありましたら、
教えて頂けませんか？（質問1）
（可能な範囲で構いません。私は業務系のシステム案件が多かったため、他分野の案件に興味があります。）

頻繁にカラムを変更、追加したりする職場が仮にあったとして、
Mysqlでもテーブル定義の更新が面倒なだけで、対応できるのであれば、Mysqlでいいのではないかと思ってしまいます。
それ以外に何かデメリットがあるのでしょうか？（質問2）
（DB周りはあまり詳しくないのですが、例えば、既存データとの整合性が合わないが故に、エラーが起き、システムが停止しまう？等）

最後に、最初に引用したメリット以外にも、便利だったという事例などありましたら、共有して
頂けると幸いです。（質問3）


以上、お手数ですが、何卒宜しくお願いします。

MongoDBのスキーマレスの良さがまだよくわかりません。実務で頻繁にカラムを変更、追加したりすることってあるんですか？

PHP・Mysqlを使いフィールドの情報を取得してJSON形式にして取得するようなことを行っていたのですが、今度は逆に**JSON形式の値をMysqlの別のテーブルに格納する**にはどうすれば良いでしょうか？
いろいろと調べてみたのですが、私自身が探している今回のタイトルに関する回答を得ることができる
記事が見当たりませんでした。

また、周りのプログラマーに聞いたところNosqlや、mongoを使うと特にコードを書かなくても突っ込めるかもしれないぞ。というのを聞きましたが周りもそれ以上の事は詳しく知らず。

このような状況で困っています。

**データを木構造で取得したJSON形式をデータベースに格納できる方法についてどなたかご存知あれば教えていただけないでしょうか？**

PHP JSON形式をデータベースに格納するには

[個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた](https://qiita.com/yuno_miyako/items/fad33456d9c32d8f4483)

上記記事で

> RDS vs DynamoDB
結論から言うと問答無用でDynamoDBを選択することを推奨します。
正確にいうとDynamoDBでは表現しきれないデータ構造や複雑すぎるアクセスパターンの場合はRDSにせざるをえないのですが、初期のフェーズではDynamoDBで作って無理が出てきたらRDSとの併用を考えるという形が良いと思います。

との記載がありました。

この記事への人気コメントとして、

[この理由でNoSQL採用すると後で死なない？NoSQLをRDBの代わりとして使わないほうがいいよ](https://b.hatena.ne.jp/entry/4693440992518414754/comment/chiroruxx)

[これ、スタートアップではものすごい技術的負債になるので、普通に RDS にしたほうがいいよ。 “初期のフェーズではDynamoDBで作って無理が出てきたらRDSとの併用を考える”](https://b.hatena.ne.jp/entry/4693440992518414754/comment/paradisemaker)

という反応がありました。


もちろんどのようなデータがどんな要件で使われるかで適する構造は変わると思いますが、一般論として、どのような要件であればRDSが適していて、どのような要件ならNoSQLが適しているのでしょうか？

また、コメントではなぜこの文脈においてNoSQLに否定的な見解が支持を集めているのでしょうか？

これから作るシステムでNoSQL採用を少し検討していたタイミングでしたので、経験のある方の率直な感触を伺えたらと思いました。

RDS vs NoSQL どう使い分ければ良いのでしょうか？

RDBMS（リレーショナルデータベース）はスケールアウトが難しく、NoSQL はスケールアウトがしやすいと[よく聞きます。](https://www.atmarkit.co.jp/ait/articles/1102/24/news098.html)

ただ、調べてみるとスケールアウトを難しくしているのは [ACID](https://ja.wikipedia.org/wiki/ACID_(%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E7%A7%91%E5%AD%A6)) や [CAP 定理](https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)のような印象を受けます。また、NoSQL のスケールアウトを容易にしているのは [BASE](https://www.publickey1.jp/blog/09/_basecap.html) や DB 製品固有の機能 (e.g. [MongoDB のシャーディング](https://www.techcrowd.jp/mongodb/sharding/?fbclid=IwAR3Hz8BfD83JMOCZ7SSCO0JAX_61aXYWkPE0Q7O8WAWcFxNn9OXXrJ5KYkM)）のような印象も受けます。

思考実験的な質問で恐縮ですが、例えば、BASE 特性に沿った、シャーディング機能のある RDBMS (e.g. スキーマの事前定義、JOIN 機能、etc.）は定義上ありえないのでしょうか？なぜ RDBMS のスケールアウトは難しく、NoSQL のスケールアウトは容易なのか、細かい仕組みから解説している資料などご存知でしたら、教えていただけますと嬉しく思います。

なぜ RDBMS はスケールアウトが難しいのでしょうか？

## 質問内容
Pythonの学習を始めて2か月の初心者です。
NoSQLの学習ページの中で'redis'なるものが紹介されており、実際に使おうと思い、importをしましたが、下記のエラーが生じました。

importする方法をご教示ください。
よろしくお願いいたします。
##該当のソースコード
```conda
conda install -c anaconda redis
```
```Python
import redis
```
## 発生しているエラー
```ここに言語を入力
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'redis'
```
##試したこと
1.標準パッケージのimport
　　問題なくimportできました。
2.標準パッケージ以外のimport（construct）
問題なくimportできました。
3.redisがインストールされているか？
　一応インストールはされています。
4.redisの保存先
　保存先がおかしいかもしれないです。


以下、詳細です。
######1. 標準パッケージのimport
```Python
import sys
sys.path
```
 実行結果
```ここに言語を入力
['', '/mnt/c/Wsl_home/miniconda3/lib/python37.zip', '/mnt/c/Wsl_home/miniconda3/lib/python3.7', '/mnt/c/Wsl_home/miniconda3/lib/python3.7/lib-dynload', '/mnt/c/Wsl_home/miniconda3/lib/python3.7/site-packages']
```
######2. 標準パッケージ以外のimport
```conda
conda install -c conda-forge construct
```
```python
import construct
construct
```
 実行結果
```ここに言語を入力
<module 'construct' from '/mnt/c/Wsl_home/miniconda3/lib/python3.7/site-packages/construct/__init__.py'>
```
######3. redisがインストールされているか？
```conda
conda list
```
 実行結果
```
<省略>
redis                     5.0.3                h7b6447c_0    anaconda
<省略>
```
######4. redisの保存先
redisの保存先を確認したところ、
/mnt/c/Wsl_home/miniconda3/bin/
にありました。
ただ、
/mnt/c/Wsl_home/miniconda3/lib/python3.7/site-packages/
には見当たりませんでした。
(これが原因なのか？と考えたりしていますが…。そもそもbinとsite-packeages両方に同じ名前のものがあったりして、意味合いを理解していないです。)

ググると、PYTHONPATH配下にredisが存在していないのではないかという指摘がありましたので、
```Python
import sys
sys.path.append(/mnt/c/Wsl_home/miniconda3/bin/)
```
としてみましたが、結果は変わらず、redisをimportできませんでした。
##補足情報（FW/ツールのバージョンなど）
OS:Windows10 
OSバージョン:1909
OSビルド:18363.778
Ubuntu: 18.04.2 LTS (Bionic Beaver)
Python: 3.7.6
PythonはUbuntuに入れたMinicondaからインストールしました。