ਆਧੁਨਿਕ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀਆਂ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਹਨ। ਸਭ ਤੋਂ ਘੱਟ ਨਹੀਂ, ਉਹਨਾਂ ਦੀ ਗੁੰਝਲਤਾ ਉਹਨਾਂ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਗਏ ਡੇਟਾ ਦੀ ਗੁੰਝਲਤਾ ਦੇ ਕਾਰਨ ਹੈ. ਡੇਟਾ ਦੀ ਗੁੰਝਲਤਾ ਅਕਸਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਡੇਟਾ ਮਾਡਲਾਂ ਦੀ ਵਿਭਿੰਨਤਾ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ, ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਡੇਟਾ "ਵੱਡਾ" ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਵਾਲੇ ਗੁਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾ ਸਿਰਫ਼ ਇਸਦਾ ਵੌਲਯੂਮ ("ਆਵਾਜ਼"), ਸਗੋਂ ਇਸਦੀ ਵਿਭਿੰਨਤਾ ("ਵਿਭਿੰਨਤਾ") ਵੀ ਹੈ।

ਜੇ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਤਰਕ ਵਿੱਚ ਕੋਈ ਨੁਕਸ ਨਹੀਂ ਮਿਲਿਆ, ਤਾਂ ਪੜ੍ਹੋ।

ਸਮੱਗਰੀ

ਪੌਲੀਗਲੋਟ ਸਥਿਰਤਾ
ਬਹੁ-ਮਾਡਲ
ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ 'ਤੇ ਆਧਾਰਿਤ ਮਲਟੀ-ਮਾਡਲ ਡੀ.ਬੀ.ਐੱਮ.ਐੱਸ
     MS SQL ਸਰਵਰ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ
     MS SQL ਸਰਵਰ ਵਿੱਚ ਗ੍ਰਾਫ ਮਾਡਲ
ਦਸਤਾਵੇਜ਼ ਮਾਡਲ 'ਤੇ ਆਧਾਰਿਤ ਮਲਟੀ-ਮਾਡਲ ਡੀ.ਬੀ.ਐੱਮ.ਐੱਸ
     MarkLogic ਵਿੱਚ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ
     MarkLogic ਵਿੱਚ ਗ੍ਰਾਫ਼ ਮਾਡਲ
ਮਲਟੀ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ "ਮੁੱਖ ਮਾਡਲ ਤੋਂ ਬਿਨਾਂ"
     ਅਰੰਗੋ ਡੀ ਬੀ
     OrientDB
     Azure CosmosDB
ਇੱਕ ਗ੍ਰਾਫ ਮਾਡਲ ਦੇ ਅਧਾਰ ਤੇ ਮਲਟੀ-ਮਾਡਲ ਡੀ.ਬੀ.ਐਮ.ਐਸ.
ਸਿੱਟਾ
ਪੋਲ

ਪੌਲੀਗਲੋਟ ਸਥਿਰਤਾ

ਉਪਰੋਕਤ ਇਸ ਤੱਥ ਵੱਲ ਖੜਦਾ ਹੈ ਕਿ ਕਈ ਵਾਰ ਇੱਕ ਸਿਸਟਮ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਵੀ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਦੀਆਂ ਕਈ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕਈ ਵੱਖ-ਵੱਖ ਡੀਬੀਐਮਐਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਆਪਣੇ ਖੁਦ ਦੇ ਡੇਟਾ ਮਾਡਲ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਐਮ. ਫੋਲਰ ਦੇ ਹਲਕੇ ਹੱਥਾਂ ਨਾਲ, ਲੇਖਕ ਕਈ ਮਸ਼ਹੂਰ ਕਿਤਾਬਾਂ ਅਤੇ ਇੱਕ ਸਹਿ-ਲੇਖਕ ਚੁਸਤ ਮੈਨੀਫੈਸਟੋ, ਇਸ ਸਥਿਤੀ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਮਲਟੀ-ਵੇਰੀਐਂਟ ਸਟੋਰੇਜ ("ਪੌਲੀਗਲੋਟ ਸਥਿਰਤਾ")।

ਫੋਲਰ ਕੋਲ ਈ-ਕਾਮਰਸ ਦੇ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਪੂਰੀ-ਵਿਸ਼ੇਸ਼ਤਾ ਅਤੇ ਉੱਚ-ਲੋਡ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰੇਜ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਹੇਠ ਲਿਖੀ ਉਦਾਹਰਣ ਵੀ ਹੈ।

ਇਹ ਉਦਾਹਰਨ, ਬੇਸ਼ੱਕ, ਕੁਝ ਅਤਿਕਥਨੀ ਹੈ, ਪਰ ਸੰਬੰਧਿਤ ਉਦੇਸ਼ ਲਈ ਇੱਕ ਜਾਂ ਕਿਸੇ ਹੋਰ DBMS ਦੀ ਚੋਣ ਕਰਨ ਦੇ ਪੱਖ ਵਿੱਚ ਕੁਝ ਵਿਚਾਰ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ.

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਅਜਿਹੇ ਚਿੜੀਆਘਰ ਵਿੱਚ ਸੇਵਕ ਬਣਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ।

• ਕੋਡ ਦੀ ਮਾਤਰਾ ਜੋ ਡਾਟਾ ਸਟੋਰੇਜ ਕਰਦੀ ਹੈ, ਵਰਤੇ ਗਏ DBMS ਦੀ ਸੰਖਿਆ ਦੇ ਅਨੁਪਾਤ ਵਿੱਚ ਵਧਦੀ ਹੈ; ਕੋਡ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ਿੰਗ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਚੰਗੀ ਹੈ ਜੇਕਰ ਇਸ ਨੰਬਰ ਦੇ ਵਰਗ ਦੇ ਅਨੁਪਾਤੀ ਨਾ ਹੋਵੇ।
• ਵਰਤੇ ਗਏ DBMSs ਦੀ ਸੰਖਿਆ ਦੇ ਗੁਣਜ ਦੇ ਰੂਪ ਵਿੱਚ, ਹਰੇਕ DBMSs ਦੀ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਸਕੇਲੇਬਿਲਟੀ, ਫਾਲਟ ਸਹਿਣਸ਼ੀਲਤਾ, ਉੱਚ ਉਪਲਬਧਤਾ) ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲਾਗਤ ਵਧਦੀ ਹੈ।
• ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਟੋਰੇਜ ਸਬ-ਸਿਸਟਮ ਦੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੈ - ਖਾਸ ਕਰਕੇ ਲੈਣ-ਦੇਣ।

ਚਿੜੀਆਘਰ ਦੇ ਨਿਰਦੇਸ਼ਕ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

• DBMS ਨਿਰਮਾਤਾ ਤੋਂ ਲਾਇਸੈਂਸਾਂ ਅਤੇ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਦੀ ਲਾਗਤ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਧਾ।
• ਓਵਰ ਸਟਾਫਿੰਗ ਅਤੇ ਵਧੀ ਹੋਈ ਸਮਾਂ ਸੀਮਾ।
• ਡੇਟਾ ਅਸੰਗਤਤਾ ਦੇ ਕਾਰਨ ਸਿੱਧੇ ਵਿੱਤੀ ਨੁਕਸਾਨ ਜਾਂ ਜੁਰਮਾਨੇ।

ਸਿਸਟਮ ਦੀ ਮਲਕੀਅਤ ਦੀ ਕੁੱਲ ਲਾਗਤ (TCO) ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਹੋਇਆ ਹੈ। ਕੀ "ਮਲਟੀਪਲ ਸਟੋਰੇਜ ਵਿਕਲਪਾਂ" ਦੀ ਸਥਿਤੀ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਹੈ?

ਬਹੁ-ਮਾਡਲ

"ਮਲਟੀਵੇਰੀਏਟ ਸਟੋਰੇਜ" ਸ਼ਬਦ 2011 ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਪਹੁੰਚ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਜਾਗਰੂਕਤਾ ਅਤੇ ਹੱਲ ਦੀ ਖੋਜ ਵਿੱਚ ਕਈ ਸਾਲ ਲੱਗ ਗਏ, ਅਤੇ 2015 ਤੱਕ, ਗਾਰਟਨਰ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਦੇ ਮੂੰਹ ਰਾਹੀਂ, ਜਵਾਬ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ:

• ਤੋਂ "NoSQL DBMSs ਲਈ ਮਾਰਕੀਟ ਗਾਈਡ - 2015"
  

  DBMSs ਦਾ ਭਵਿੱਖ, ਉਹਨਾਂ ਦੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਰਤਣ ਦੇ ਤਰੀਕੇ ਬਹੁ-ਮਾਡਲ ਹਨ।

• ਤੋਂ "ODBMS - 2016 ਲਈ ਮੈਜਿਕ ਕੁਆਡਰੈਂਟ"
  

  ਪ੍ਰਮੁੱਖ ਸੰਚਾਲਨ DBMSs ਇੱਕ ਸਿੰਗਲ ਪਲੇਟਫਾਰਮ ਦੇ ਹਿੱਸੇ ਦੇ ਰੂਪ ਵਿੱਚ ਕਈ ਮਾਡਲ ਪੇਸ਼ ਕਰਨਗੇ - ਰਿਲੇਸ਼ਨਲ ਅਤੇ ਗੈਰ-ਰਿਲੇਸ਼ਨਲ -।

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਸ ਵਾਰ ਗਾਰਟਨਰ ਵਿਸ਼ਲੇਸ਼ਕ ਆਪਣੀ ਭਵਿੱਖਬਾਣੀ ਨਾਲ ਸਹੀ ਸਨ. ਜੇ ਤੁਸੀਂ ਨਾਲ ਪੰਨੇ 'ਤੇ ਜਾਂਦੇ ਹੋ ਮੁੱਖ ਰੇਟਿੰਗ DB-ਇੰਜਣਾਂ 'ਤੇ DBMS, ਤੁਸੀਂ ਇਹ ਦੇਖ ਸਕਦੇ ਹੋоਇਸਦੇ ਬਹੁਤੇ ਨੇਤਾ ਆਪਣੇ ਆਪ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮਲਟੀ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ ਦੇ ਤੌਰ 'ਤੇ ਰੱਖਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਪ੍ਰਾਈਵੇਟ ਰੇਟਿੰਗ ਦੇ ਨਾਲ ਪੰਨੇ 'ਤੇ ਵੀ ਇਹੀ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ DBMS ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ - ਹਰੇਕ ਪ੍ਰਾਈਵੇਟ ਰੇਟਿੰਗ ਵਿੱਚ ਲੀਡਰ, ਜੋ ਬਹੁ-ਮਾਡਲ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ। ਹਰੇਕ DBMS ਲਈ, ਮੂਲ ਸਮਰਥਿਤ ਮਾਡਲ (ਜੋ ਕਿ ਇੱਕ ਵਾਰ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਸੀ) ਅਤੇ ਇਸਦੇ ਨਾਲ ਮੌਜੂਦਾ ਸਮਰਥਿਤ ਮਾਡਲਾਂ ਨੂੰ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। DBMSs ਨੂੰ ਵੀ ਸੂਚੀਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ "ਅਸਲ ਵਿੱਚ ਬਹੁ-ਮਾਡਲ" ਦੇ ਰੂਪ ਵਿੱਚ ਪਦਵੀ ਰੱਖਦੇ ਹਨ ਅਤੇ, ਸਿਰਜਣਹਾਰਾਂ ਦੇ ਅਨੁਸਾਰ, ਕੋਈ ਵੀ ਸ਼ੁਰੂਆਤੀ ਵਿਰਾਸਤੀ ਮਾਡਲ ਨਹੀਂ ਹੈ।

ਟੇਬਲ 'ਤੇ ਨੋਟਸ

ਸਾਰਣੀ ਵਿੱਚ ਤਾਰੇ ਉਹਨਾਂ ਕਥਨਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰਦੇ ਹਨ ਜਿਹਨਾਂ ਲਈ ਰਾਖਵੇਂਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

• PostgreSQL DBMS ਗ੍ਰਾਫ ਡੇਟਾ ਮਾਡਲ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਉਤਪਾਦ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਇਸ 'ਤੇ ਆਧਾਰਿਤ, ਜਿਵੇਂ ਕਿ AgensGraph।
• ਮੋਂਗੋਡੀਬੀ ਦੇ ਸਬੰਧ ਵਿੱਚ, ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਵਿੱਚ ਗ੍ਰਾਫ ਓਪਰੇਟਰਾਂ ਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਵਧੇਰੇ ਸਹੀ ਹੈ ($lookup, $graphLookup) ਗ੍ਰਾਫ ਮਾਡਲ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਬਜਾਏ, ਹਾਲਾਂਕਿ, ਬੇਸ਼ੱਕ, ਉਹਨਾਂ ਦੀ ਜਾਣ-ਪਛਾਣ ਲਈ ਗ੍ਰਾਫ ਮਾਡਲ ਦੇ ਸਮਰਥਨ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ ਭੌਤਿਕ ਸਟੋਰੇਜ ਪੱਧਰ 'ਤੇ ਕੁਝ ਅਨੁਕੂਲਨ ਦੀ ਲੋੜ ਸੀ।
• Redis ਦੇ ਸਬੰਧ ਵਿੱਚ, ਸਾਡਾ ਮਤਲਬ ਹੈ ਐਕਸਟੈਂਸ਼ਨ RedisGraph.

ਅੱਗੇ, ਹਰੇਕ ਕਲਾਸ ਲਈ, ਅਸੀਂ ਦਿਖਾਵਾਂਗੇ ਕਿ ਇਸ ਕਲਾਸ ਤੋਂ DBMS ਵਿੱਚ ਕਈ ਮਾਡਲਾਂ ਲਈ ਸਮਰਥਨ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਰਿਲੇਸ਼ਨਲ, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਗ੍ਰਾਫ ਮਾਡਲਾਂ ਨੂੰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਮੰਨਾਂਗੇ ਅਤੇ ਇਹ ਦਿਖਾਉਣ ਲਈ ਖਾਸ DBMSs ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ ਕਿ "ਗੁੰਮ ਹੋਏ" ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ 'ਤੇ ਆਧਾਰਿਤ ਮਲਟੀ-ਮਾਡਲ ਡੀ.ਬੀ.ਐੱਮ.ਐੱਸ

ਪ੍ਰਮੁੱਖ DBMSs ਵਰਤਮਾਨ ਵਿੱਚ ਰਿਲੇਸ਼ਨਲ ਹਨ; ਗਾਰਟਨਰ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨੂੰ ਸੱਚ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ RDBMSs ਬਹੁ-ਮਾਡਲਿੰਗ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ ਗਤੀ ਨਹੀਂ ਦਿਖਾਉਂਦੇ। ਅਤੇ ਉਹ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ. ਹੁਣ ਇਹ ਵਿਚਾਰ ਕਿ ਇੱਕ ਬਹੁ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ ਇੱਕ ਸਵਿਸ ਚਾਕੂ ਵਰਗਾ ਹੈ, ਜੋ ਕੁਝ ਵੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਸਿੱਧੇ ਲੈਰੀ ਐਲੀਸਨ ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਲੇਖਕ, ਹਾਲਾਂਕਿ, ਮਾਈਕ੍ਰੋਸਾੱਫਟ SQL ਸਰਵਰ ਵਿੱਚ ਮਲਟੀ-ਮਾਡਲਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਜਿਸਦੀ ਉਦਾਹਰਣ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਗ੍ਰਾਫ ਮਾਡਲਾਂ ਲਈ RDBMS ਸਮਰਥਨ ਦਾ ਵਰਣਨ ਕੀਤਾ ਜਾਵੇਗਾ।

MS SQL ਸਰਵਰ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ

ਹੈਬਰੇ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਦੋ ਸ਼ਾਨਦਾਰ ਲੇਖ ਹਨ ਕਿ ਕਿਵੇਂ MS SQL ਸਰਵਰ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਲਈ ਸਮਰਥਨ ਲਾਗੂ ਕਰਦਾ ਹੈ; ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਸੰਖੇਪ ਰੀਟੇਲਿੰਗ ਅਤੇ ਟਿੱਪਣੀ ਤੱਕ ਸੀਮਤ ਕਰਾਂਗਾ:

• SQL ਸਰਵਰ 2016 ਵਿੱਚ JSON ਨਾਲ ਕੰਮ ਕਰਨਾ
• SQL ਸਰਵਰ 2017 JSON

MS SQL ਸਰਵਰ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦਾ ਤਰੀਕਾ ਰਿਲੇਸ਼ਨਲ DBMSs ਲਈ ਕਾਫ਼ੀ ਆਮ ਹੈ: JSON ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਆਮ ਟੈਕਸਟ ਖੇਤਰਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਦੀ ਤਜਵੀਜ਼ ਹੈ। ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਲਈ ਸਮਰਥਨ ਇਸ JSON ਨੂੰ ਪਾਰਸ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਓਪਰੇਟਰ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ:

• JSON_VALUE ਸਕੇਲਰ ਗੁਣ ਮੁੱਲਾਂ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਲਈ,
• JSON_QUERY ਉਪ-ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਲਈ।

ਦੋਵਾਂ ਓਪਰੇਟਰਾਂ ਦੀ ਦੂਜੀ ਦਲੀਲ JSONPath-ਵਰਗੇ ਸੰਟੈਕਸ ਵਿੱਚ ਇੱਕ ਸਮੀਕਰਨ ਹੈ।

ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਟੋਰ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ ਟੂਪਲਾਂ ਦੇ ਉਲਟ, ਇੱਕ ਸੰਬੰਧਤ DBMS ਵਿੱਚ "ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਦੀਆਂ ਸੰਸਥਾਵਾਂ" ਨਹੀਂ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ, MS SQL ਸਰਵਰ ਵਿੱਚ ਵਰਤਮਾਨ ਵਿੱਚ JSON ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਖੇਤਰਾਂ 'ਤੇ ਕੋਈ ਸੂਚਕਾਂਕ ਨਹੀਂ ਹਨ, ਜੋ ਇਹਨਾਂ ਖੇਤਰਾਂ ਦੇ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟੇਬਲਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਅਤੇ ਇਹਨਾਂ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਵੀ ਚੁਣਨਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਜਿਹੇ ਖੇਤਰ ਲਈ ਇੱਕ ਗਣਿਤ ਕਾਲਮ ਅਤੇ ਇਸ 'ਤੇ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, MS SQL ਸਰਵਰ ਆਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟੇਬਲਾਂ ਦੀ ਸਮਗਰੀ ਤੋਂ ਇੱਕ JSON ਦਸਤਾਵੇਜ਼ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ FOR JSON PATH - ਇੱਕ ਸੰਭਾਵਨਾ, ਇੱਕ ਖਾਸ ਅਰਥ ਵਿੱਚ, ਪਿਛਲੇ ਇੱਕ ਦੇ ਉਲਟ, ਰਵਾਇਤੀ ਸਟੋਰੇਜ। ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਭਾਵੇਂ ਇੱਕ RDBMS ਕਿੰਨੀ ਵੀ ਤੇਜ਼ ਹੋਵੇ, ਇਹ ਪਹੁੰਚ ਦਸਤਾਵੇਜ਼ DBMSs ਦੀ ਵਿਚਾਰਧਾਰਾ ਦਾ ਖੰਡਨ ਕਰਦੀ ਹੈ, ਜੋ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰਸਿੱਧ ਸਵਾਲਾਂ ਦੇ ਤਿਆਰ ਜਵਾਬਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਸਿਰਫ ਵਿਕਾਸ ਦੀ ਸੌਖ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਗਤੀ ਨਹੀਂ।

ਅੰਤ ਵਿੱਚ, MS SQL ਸਰਵਰ ਤੁਹਾਨੂੰ ਦਸਤਾਵੇਜ਼ ਨਿਰਮਾਣ ਦੀ ਉਲਟ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ: ਤੁਸੀਂ JSON ਨੂੰ ਟੇਬਲਾਂ ਵਿੱਚ ਕੰਪੋਜ਼ ਕਰ ਸਕਦੇ ਹੋ OPENJSON. ਜੇਕਰ ਦਸਤਾਵੇਜ਼ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਲੈਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਵਰਤਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ CROSS APPLY.

MS SQL ਸਰਵਰ ਵਿੱਚ ਗ੍ਰਾਫ ਮਾਡਲ

ਗ੍ਰਾਫ (LPG) ਮਾਡਲ ਲਈ ਸਮਰਥਨ Microsoft SQL ਸਰਵਰ ਵਿੱਚ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਨੁਮਾਨ ਲਗਾਉਣ ਯੋਗ: ਨੋਡਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਗ੍ਰਾਫ ਦੇ ਕਿਨਾਰਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਟੇਬਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਹੈ। ਅਜਿਹੀਆਂ ਟੇਬਲ ਸਮੀਕਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ CREATE TABLE AS NODE и CREATE TABLE AS EDGE ਕ੍ਰਮਵਾਰ.

ਪਹਿਲੀ ਕਿਸਮ ਦੇ ਟੇਬਲ ਰਿਕਾਰਡ ਸਟੋਰ ਕਰਨ ਲਈ ਆਮ ਟੇਬਲਾਂ ਦੇ ਸਮਾਨ ਹੁੰਦੇ ਹਨ, ਸਿਰਫ ਬਾਹਰੀ ਫਰਕ ਇਹ ਹੈ ਕਿ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਸਿਸਟਮ ਫੀਲਡ ਹੁੰਦਾ ਹੈ $node_id - ਡੇਟਾਬੇਸ ਦੇ ਅੰਦਰ ਇੱਕ ਗ੍ਰਾਫ ਨੋਡ ਦਾ ਵਿਲੱਖਣ ਪਛਾਣਕਰਤਾ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਦੂਜੀ ਕਿਸਮ ਦੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਸਿਸਟਮ ਖੇਤਰ ਹੁੰਦੇ ਹਨ $from_id и $to_id, ਅਜਿਹੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਐਂਟਰੀਆਂ ਨੋਡਾਂ ਵਿਚਕਾਰ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ। ਹਰੇਕ ਕਿਸਮ ਦੇ ਸਬੰਧਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰੀ ਸਾਰਣੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।

ਆਉ ਇਸ ਨੂੰ ਇੱਕ ਉਦਾਹਰਣ ਨਾਲ ਸਮਝੀਏ। ਗ੍ਰਾਫ ਡੇਟਾ ਦਾ ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਇੱਕ ਖਾਕਾ ਹੋਣ ਦਿਓ। ਫਿਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਅਨੁਸਾਰੀ ਢਾਂਚਾ ਬਣਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ DDL ਸਵਾਲਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ:

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

ਅਜਿਹੀਆਂ ਟੇਬਲਾਂ ਦੀ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਦੇ ਵਿਰੁੱਧ ਸਵਾਲਾਂ ਵਿੱਚ ਸਾਈਫਰ-ਵਰਗੇ ਸੰਟੈਕਸ ਨਾਲ ਗ੍ਰਾਫ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੈ (ਹਾਲਾਂਕਿ, "*"ਆਦਿ ਅਜੇ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ)। ਕਾਰਗੁਜ਼ਾਰੀ ਮਾਪਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਇਹ ਵੀ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਟੇਬਲਾਂ ਵਿੱਚ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਿਯਮਤ ਟੇਬਲਾਂ ਵਿੱਚ ਡਾਟਾ ਸਟੋਰ ਕੀਤੇ ਜਾਣ ਦੇ ਤਰੀਕੇ ਤੋਂ ਵੱਖਰਾ ਹੈ ਅਤੇ ਅਜਿਹੀਆਂ ਗ੍ਰਾਫ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ।

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਜਿਹੀਆਂ ਟੇਬਲਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇਹਨਾਂ ਗ੍ਰਾਫ ਪੈਟਰਨਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ, ਕਿਉਂਕਿ ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਸਧਾਰਣ SQL ਪ੍ਰਸ਼ਨਾਂ ਵਿੱਚ ਸਿਸਟਮ "ਗ੍ਰਾਫ" ਨੋਡ ਪਛਾਣਕਰਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਾਧੂ ਯਤਨ ਕਰਨੇ ਜ਼ਰੂਰੀ ਹੋਣਗੇ ($node_id, $from_id, $to_id; ਇਸੇ ਕਾਰਨ ਕਰਕੇ, ਡੇਟਾ ਸੰਮਿਲਿਤ ਕਰਨ ਲਈ ਸਵਾਲ ਇੱਥੇ ਨਹੀਂ ਦਿਖਾਏ ਗਏ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬੇਲੋੜੇ ਬੋਝਲ ਹਨ)।

MS SQL ਸਰਵਰ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਗ੍ਰਾਫ ਮਾਡਲਾਂ ਦੇ ਲਾਗੂਕਰਨ ਦੇ ਵਰਣਨ ਨੂੰ ਸੰਖੇਪ ਕਰਨ ਲਈ, ਮੈਂ ਨੋਟ ਕਰਾਂਗਾ ਕਿ ਇੱਕ ਮਾਡਲ ਦੇ ਦੂਜੇ ਦੇ ਉੱਪਰ ਅਜਿਹੇ ਲਾਗੂਕਰਨ ਸਫਲ ਨਹੀਂ ਜਾਪਦੇ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਭਾਸ਼ਾ ਡਿਜ਼ਾਈਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ। ਇੱਕ ਭਾਸ਼ਾ ਨੂੰ ਦੂਜੀ ਨਾਲ ਵਧਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਭਾਸ਼ਾਵਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ "ਆਰਥੋਗੋਨਲ" ਨਹੀਂ ਹਨ, ਅਨੁਕੂਲਤਾ ਨਿਯਮ ਕਾਫ਼ੀ ਅਜੀਬ ਹੋ ਸਕਦੇ ਹਨ.

ਦਸਤਾਵੇਜ਼ ਮਾਡਲ 'ਤੇ ਆਧਾਰਿਤ ਮਲਟੀ-ਮਾਡਲ ਡੀ.ਬੀ.ਐੱਮ.ਐੱਸ

ਇਸ ਭਾਗ ਵਿੱਚ, ਮੈਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧ ਨਹੀਂ, ਮੋਂਗੋਡੀਬੀ (ਜਿਵੇਂ ਕਿਹਾ ਗਿਆ ਸੀ, ਇਸ ਵਿੱਚ ਸਿਰਫ ਕੰਡੀਸ਼ਨਲ ਗ੍ਰਾਫ ਓਪਰੇਟਰ ਹਨ) ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ ਦਸਤਾਵੇਜ਼ ਡੀਬੀਐਮਐਸ ਵਿੱਚ ਮਲਟੀ-ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨੂੰ ਦਰਸਾਉਣਾ ਚਾਹਾਂਗਾ। $lookup и $graphLookup. MarkLogic.

ਇਸ ਲਈ, ਸੰਗ੍ਰਹਿ ਵਿੱਚ ਹੇਠ ਲਿਖੀ ਕਿਸਮ ਦੇ XML ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸ਼ਾਮਲ ਹੋਣ ਦਿਓ (ਮਾਰਕਲੌਜਿਕ ਤੁਹਾਨੂੰ JSON ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

MarkLogic ਵਿੱਚ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ

ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਦਾ ਇੱਕ ਸੰਬੰਧਤ ਦ੍ਰਿਸ਼ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਡਿਸਪਲੇ ਟੈਮਪਲੇਟ (ਤੱਤਾਂ ਦੀ ਸਮੱਗਰੀ value ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਵਿੱਚ ਇੱਕ ਮਨਮਾਨੀ XPath ਹੋ ਸਕਦਾ ਹੈ):

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

ਤੁਸੀਂ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਨਾਲ ਬਣਾਏ ਦ੍ਰਿਸ਼ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ODBC ਰਾਹੀਂ):

SELECT name, surname FROM Person WHERE name="John"

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਡਿਸਪਲੇ ਟੈਂਪਲੇਟ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਰਿਲੇਸ਼ਨਲ ਦ੍ਰਿਸ਼ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਹੈ। ਇਸਦੇ ਲਈ ਇੱਕ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਸਮੇਂ, MarkLogic ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ ਦਸਤਾਵੇਜ਼ ਸੂਚਕਾਂਕ. ਪਹਿਲਾਂ, ਮਾਰਕਲੌਜਿਕ ਦੇ ਸੀਮਤ ਰਿਲੇਸ਼ਨਲ ਵਿਚਾਰ ਸਨ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੂਚਕਾਂਕ ਅਧਾਰਤ ਅਤੇ ਲਿਖਣਯੋਗ, ਪਰ ਹੁਣ ਉਹਨਾਂ ਨੂੰ ਬਰਤਰਫ਼ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

MarkLogic ਵਿੱਚ ਗ੍ਰਾਫ਼ ਮਾਡਲ

ਗ੍ਰਾਫ (RDF) ਮਾਡਲ ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ, ਸਭ ਕੁਝ ਇੱਕੋ ਜਿਹਾ ਹੈ। ਦੀ ਮਦਦ ਨਾਲ ਦੁਬਾਰਾ ਡਿਸਪਲੇ ਟੈਮਪਲੇਟ ਤੁਸੀਂ ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਤੋਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਦੀ ਇੱਕ RDF ਨੁਮਾਇੰਦਗੀ ਬਣਾ ਸਕਦੇ ਹੋ:

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

ਤੁਸੀਂ ਇੱਕ SPARQL ਪੁੱਛਗਿੱਛ ਨਾਲ ਨਤੀਜੇ ਵਜੋਂ RDF ਗ੍ਰਾਫ਼ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰ ਸਕਦੇ ਹੋ:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

ਰਿਲੇਸ਼ਨਲ ਦੇ ਉਲਟ, MarkLogic ਗ੍ਰਾਫ ਮਾਡਲ ਨੂੰ ਦੋ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਸਮਰਥਨ ਕਰਦਾ ਹੈ:

1. ਇੱਕ DBMS RDF ਡੇਟਾ ਦਾ ਇੱਕ ਪੂਰਾ-ਵੱਡਾ ਵੱਖਰਾ ਸਟੋਰੇਜ ਹੋ ਸਕਦਾ ਹੈ (ਇਸ ਵਿੱਚ ਤਿੰਨਾਂ ਨੂੰ ਕਿਹਾ ਜਾਵੇਗਾ ਪ੍ਰਬੰਧਿਤ ਉੱਪਰ ਦੱਸੇ ਗਏ ਲੋਕਾਂ ਦੇ ਉਲਟ ਕੱractedਿਆ).
2. ਵਿਸ਼ੇਸ਼ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ RDF ਨੂੰ ਸਿਰਫ਼ XML ਜਾਂ JSON ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ (ਅਤੇ ਤਿੰਨਾਂ ਨੂੰ ਫਿਰ ਬੁਲਾਇਆ ਜਾਵੇਗਾ ਪ੍ਰਬੰਧਨ ਰਹਿਤ). ਇਹ ਸ਼ਾਇਦ ਮਕੈਨਿਜ਼ਮ ਦਾ ਬਦਲ ਹੈ idref ਅਤੇ ਹੋਰ.

MarkLogic ਵਿੱਚ ਚੀਜ਼ਾਂ "ਅਸਲ ਵਿੱਚ" ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਇਸਦਾ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਦੁਆਰਾ ਦਿੱਤਾ ਗਿਆ ਹੈ ਆਪਟੀਕਲ API, ਇਸ ਅਰਥ ਵਿੱਚ, ਇਹ ਨੀਵਾਂ-ਪੱਧਰ ਹੈ, ਹਾਲਾਂਕਿ ਇਸਦਾ ਉਦੇਸ਼ ਇਸਦੇ ਉਲਟ ਹੈ - ਵਰਤੇ ਗਏ ਡੇਟਾ ਮਾਡਲ ਤੋਂ ਵੱਖ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ, ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਵਿੱਚ ਡੇਟਾ ਦੇ ਨਾਲ ਇਕਸਾਰ ਕੰਮ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਲੈਣ-ਦੇਣ, ਆਦਿ।

ਮਲਟੀ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ "ਮੁੱਖ ਮਾਡਲ ਤੋਂ ਬਿਨਾਂ"

ਮਾਰਕੀਟ ਵਿੱਚ DBMSs ਵੀ ਹਨ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਤੌਰ 'ਤੇ ਮਲਟੀ-ਮਾਡਲ ਦੇ ਤੌਰ 'ਤੇ ਸਥਿਤੀ ਵਿੱਚ ਰੱਖਦੇ ਹਨ, ਬਿਨਾਂ ਕਿਸੇ ਵਿਰਾਸਤੀ ਮੁੱਖ ਮਾਡਲ ਦੇ। ਇਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਅਰੰਗੋ ਡੀ ਬੀ, OrientDB (2018 ਤੋਂ ਵਿਕਾਸ ਕੰਪਨੀ SAP ਨਾਲ ਸਬੰਧਤ ਹੈ) ਅਤੇ CosmosDB (Microsoft Azure ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸੇਵਾ)।

ਅਸਲ ਵਿੱਚ, ArangoDB ਅਤੇ OrientDB ਵਿੱਚ "ਕੋਰ" ਮਾਡਲ ਹਨ। ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਡੇਟਾ ਮਾਡਲ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਦੇ ਸਧਾਰਣਕਰਨ ਹਨ। ਸਧਾਰਣਕਰਨ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕ ਗ੍ਰਾਫ ਅਤੇ ਰਿਲੇਸ਼ਨਲ ਪ੍ਰਕਿਰਤੀ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੀ ਸਹੂਲਤ ਲਈ ਹੁੰਦੇ ਹਨ।

ਇਹ ਮਾਡਲ ਨਿਰਧਾਰਿਤ DBMS ਵਿੱਚ ਵਰਤੋਂ ਲਈ ਉਪਲਬਧ ਹਨ; ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾਵਾਂ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਬੇਸ਼ੱਕ, ਅਜਿਹੇ ਮਾਡਲ ਅਤੇ ਡੀਬੀਐਮਐਸ ਵਾਅਦਾ ਕਰਨ ਵਾਲੇ ਹਨ, ਪਰ ਮਿਆਰੀ ਮਾਡਲਾਂ ਅਤੇ ਭਾਸ਼ਾਵਾਂ ਦੇ ਨਾਲ ਅਨੁਕੂਲਤਾ ਦੀ ਘਾਟ ਕਾਰਨ ਇਹਨਾਂ ਡੀਬੀਐਮਐਸ ਨੂੰ ਵਿਰਾਸਤੀ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਵਰਤਣਾ ਅਸੰਭਵ ਬਣਾ ਦਿੰਦਾ ਹੈ - ਪਹਿਲਾਂ ਹੀ ਵਰਤੇ ਗਏ ਡੀਬੀਐਮਐਸ ਨੂੰ ਬਦਲਣ ਲਈ।

Habré 'ਤੇ ArangoDB ਅਤੇ OrientDB ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸ਼ਾਨਦਾਰ ਲੇਖ ਸੀ: NoSQL ਡੇਟਾਬੇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ.

ਅਰੰਗੋ ਡੀ ਬੀ

ArangoDB ਇੱਕ ਗ੍ਰਾਫ ਡੇਟਾ ਮਾਡਲ ਲਈ ਸਮਰਥਨ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ।

ArangoDB ਵਿੱਚ ਇੱਕ ਗ੍ਰਾਫ ਦੇ ਨੋਡ ਸਾਧਾਰਨ ਦਸਤਾਵੇਜ਼ ਹਨ, ਅਤੇ ਕਿਨਾਰੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਿਸਮ ਦੇ ਦਸਤਾਵੇਜ਼ ਹਨ, ਜੋ ਕਿ ਨਿਯਮਤ ਸਿਸਟਮ ਖੇਤਰਾਂ ਦੇ ਨਾਲ, (_key, _id, _rev) ਸਿਸਟਮ ਖੇਤਰ _from и _to. ਦਸਤਾਵੇਜ਼ DBMS ਵਿੱਚ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਸੰਗ੍ਰਹਿ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਕਿਨਾਰਿਆਂ ਨੂੰ ਦਰਸਾਉਣ ਵਾਲੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਨੂੰ ArangoDB ਵਿੱਚ ਕਿਨਾਰੇ ਸੰਗ੍ਰਹਿ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਤਰੀਕੇ ਨਾਲ, ਕਿਨਾਰੇ ਸੰਗ੍ਰਹਿ ਦਸਤਾਵੇਜ਼ ਵੀ ਦਸਤਾਵੇਜ਼ ਹਨ, ਇਸਲਈ ArangoDB ਵਿੱਚ ਕਿਨਾਰੇ ਨੋਡ ਦੇ ਤੌਰ ਤੇ ਵੀ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ।

ਸ਼ੁਰੂਆਤੀ ਡੇਟਾ

ਸਾਡੇ ਕੋਲ ਇੱਕ ਸੰਗ੍ਰਹਿ ਹੈ persons, ਜਿਸ ਦੇ ਦਸਤਾਵੇਜ਼ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

ਇੱਕ ਸੰਗ੍ਰਹਿ ਵੀ ਹੋਣ ਦਿਓ cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

ਫਿਰ ਸੰਗ੍ਰਹਿ likes ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ:

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

ਸਵਾਲ ਅਤੇ ਨਤੀਜੇ

ArangoDB ਵਿੱਚ ਵਰਤੀ ਗਈ AQL ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਗ੍ਰਾਫ-ਸ਼ੈਲੀ ਦੀ ਪੁੱਛਗਿੱਛ, ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ ਰੂਪ ਵਿੱਚ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕਰ ਰਹੀ ਹੈ ਕਿ ਕਿਸ ਨੂੰ ਕਿਹੜਾ ਕੈਫੇ ਪਸੰਦ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਸ਼ੈਲੀ ਵਿੱਚ, ਜਿੱਥੇ ਅਸੀਂ ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਬਜਾਏ "ਕੰਪਿਊਟਿੰਗ" ਕਰ ਰਹੇ ਹਾਂ, ਇਸ ਪੁੱਛਗਿੱਛ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਤਰੀਕੇ ਨਾਲ, ਸੰਗ੍ਰਹਿ ਤੋਂ ਬਿਨਾਂ likes ਬਿਨਾਂ ਕਰ ਸਕਦਾ ਹੈ):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਨਤੀਜਾ ਇੱਕੋ ਜਿਹਾ ਹੋਵੇਗਾ:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

ਹੋਰ ਸਵਾਲ ਅਤੇ ਨਤੀਜੇ

ਜੇਕਰ ਉਪਰੋਕਤ ਨਤੀਜਾ ਫਾਰਮੈਟ ਕਿਸੇ ਦਸਤਾਵੇਜ਼ DBMS ਦੀ ਬਜਾਏ ਰਿਲੇਸ਼ਨਲ DBMS ਲਈ ਵਧੇਰੇ ਆਮ ਜਾਪਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਪੁੱਛਗਿੱਛ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ (ਜਾਂ ਤੁਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

ਨਤੀਜਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

OrientDB ਵਿੱਚ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਦੇ ਸਿਖਰ 'ਤੇ ਇੱਕ ਗ੍ਰਾਫ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਆਧਾਰ ਹੈ ਮੌਕਾ ਡੌਕੂਮੈਂਟ ਫੀਲਡ, ਘੱਟ ਜਾਂ ਘੱਟ ਸਟੈਂਡਰਡ ਸਕੇਲਰ ਵੈਲਯੂਜ਼ ਤੋਂ ਇਲਾਵਾ, ਕਿਸਮਾਂ ਦੇ ਮੁੱਲ ਵੀ ਹੁੰਦੇ ਹਨ ਜਿਵੇਂ ਕਿ LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. ਇਹਨਾਂ ਕਿਸਮਾਂ ਦੇ ਮੁੱਲ ਲਿੰਕਾਂ ਦੇ ਲਿੰਕ ਜਾਂ ਸੰਗ੍ਰਹਿ ਹਨ ਸਿਸਟਮ ਪਛਾਣਕਰਤਾ ਦਸਤਾਵੇਜ਼।

ਸਿਸਟਮ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਦਸਤਾਵੇਜ਼ ਪਛਾਣਕਰਤਾ ਦਾ "ਭੌਤਿਕ ਅਰਥ" ਹੁੰਦਾ ਹੈ, ਜੋ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਿਕਾਰਡ ਦੀ ਸਥਿਤੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: @rid : #3:16. ਇਸ ਤਰ੍ਹਾਂ, ਸੰਦਰਭ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਮੁੱਲ ਚੋਣ ਸਥਿਤੀਆਂ (ਜਿਵੇਂ ਕਿ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਵਿੱਚ) ਦੀ ਬਜਾਏ ਅਸਲ ਵਿੱਚ ਪੁਆਇੰਟਰ ਹਨ (ਜਿਵੇਂ ਕਿ ਗ੍ਰਾਫ ਮਾਡਲ ਵਿੱਚ)।

ArangoDB ਦੀ ਤਰ੍ਹਾਂ, OrientDB ਵਿੱਚ ਕਿਨਾਰਿਆਂ ਨੂੰ ਵੱਖਰੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ (ਹਾਲਾਂਕਿ ਜੇਕਰ ਇੱਕ ਕਿਨਾਰੇ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਹੀਂ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਲਕਾ, ਅਤੇ ਇਹ ਇੱਕ ਵੱਖਰੇ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ)।

ਸ਼ੁਰੂਆਤੀ ਡੇਟਾ

ਦੇ ਨੇੜੇ ਇੱਕ ਫਾਰਮੈਟ ਵਿੱਚ ਡੰਪ ਫਾਰਮੈਟ OrientDB ਡੇਟਾਬੇਸ, ArangoDB ਲਈ ਪਿਛਲੀ ਉਦਾਹਰਨ ਤੋਂ ਡੇਟਾ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਸਿਰਲੇਖ ਆਉਣ ਵਾਲੇ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਿਨਾਰਿਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਵੀ ਸਟੋਰ ਕਰਦੇ ਹਨ। ਵਿਖੇ ਵਰਤ ਡੌਕੂਮੈਂਟ ਏਪੀਆਈ ਨੂੰ ਖੁਦ ਰੈਫਰੈਂਸ਼ੀਅਲ ਇਕਸਾਰਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਗ੍ਰਾਫ ਏਪੀਆਈ ਇਸ ਕੰਮ ਨੂੰ ਲੈਂਦਾ ਹੈ। ਪਰ ਆਓ ਦੇਖੀਏ ਕਿ "ਸ਼ੁੱਧ" ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਓਰੀਐਂਟਡੀਬੀ ਤੱਕ ਪਹੁੰਚ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਜੋ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਨਹੀਂ ਹਨ।

ਸਵਾਲ ਅਤੇ ਨਤੀਜੇ

OrientDB ਵਿੱਚ ArangoDB ਲਈ ਉਦਾਹਰਨ ਤੋਂ ਪੁੱਛਗਿੱਛ ਦੇ ਉਦੇਸ਼ ਦੇ ਸਮਾਨ ਇੱਕ ਪੁੱਛਗਿੱਛ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

ਨਤੀਜਾ ਹੇਠ ਲਿਖੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਵੇਗਾ:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

ਜੇਕਰ ਨਤੀਜਾ ਫਾਰਮੈਟ ਦੁਬਾਰਾ ਬਹੁਤ “ਰਿਲੇਸ਼ਨਲ” ਜਾਪਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਨਾਲ ਲਾਈਨ ਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

OrientDB ਦੀ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਨੂੰ ਗਰੇਮਲਿਨ-ਵਰਗੇ ਸੰਮਿਲਨਾਂ ਦੇ ਨਾਲ SQL ਦੇ ਰੂਪ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸੰਸਕਰਣ 2.2 ਵਿੱਚ, ਇੱਕ ਸਾਈਫਰ ਵਰਗਾ ਬੇਨਤੀ ਫਾਰਮ ਪ੍ਰਗਟ ਹੋਇਆ, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

ਨਤੀਜਾ ਫਾਰਮੈਟ ਪਿਛਲੀ ਬੇਨਤੀ ਵਾਂਗ ਹੀ ਹੋਵੇਗਾ। ਇਸ ਬਾਰੇ ਸੋਚੋ ਕਿ ਇਸਨੂੰ ਹੋਰ "ਰਿਲੇਸ਼ਨਲ" ਬਣਾਉਣ ਲਈ ਕੀ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਹਿਲੀ ਪੁੱਛਗਿੱਛ ਵਿੱਚ।

Azure CosmosDB

ਕੁਝ ਹੱਦ ਤੱਕ, ArangoDB ਅਤੇ OrientDB ਬਾਰੇ ਉੱਪਰ ਜੋ ਕਿਹਾ ਗਿਆ ਸੀ ਉਹ Azure CosmosDB 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। CosmosDB ਹੇਠਾਂ ਦਿੱਤੇ ਡੇਟਾ ਐਕਸੈਸ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: SQL, MongoDB, Gremlin ਅਤੇ Cassandra.

SQL API ਅਤੇ MongoDB API ਨੂੰ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਵਿੱਚ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। Gremlin API ਅਤੇ Cassandra API - ਕ੍ਰਮਵਾਰ ਗ੍ਰਾਫ ਅਤੇ ਕਾਲਮ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਡੇਟਾ ਐਕਸੈਸ ਕਰਨ ਲਈ। ਸਾਰੇ ਮਾਡਲਾਂ ਵਿੱਚ ਡੇਟਾ CosmosDB ਅੰਦਰੂਨੀ ਮਾਡਲ ਫਾਰਮੈਟ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ARS (“ਐਟਮ-ਰਿਕਾਰਡ-ਕ੍ਰਮ”), ਜੋ ਕਿ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਦੇ ਨੇੜੇ ਵੀ ਹੈ।

ਪਰ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਚੁਣਿਆ ਗਿਆ ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਵਰਤਿਆ ਗਿਆ API ਸੇਵਾ ਵਿੱਚ ਖਾਤਾ ਬਣਾਉਣ ਦੇ ਸਮੇਂ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਮਾਡਲ ਵਿੱਚ ਲੋਡ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਦੂਜੇ ਮਾਡਲ ਦੇ ਫਾਰਮੈਟ ਵਿੱਚ ਐਕਸੈਸ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕਿਸੇ ਚੀਜ਼ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ:

ਇਸ ਤਰ੍ਹਾਂ, Azure CosmosDB ਵਿੱਚ ਮਲਟੀ-ਮਾਡਲ ਅੱਜ ਇੱਕ ਨਿਰਮਾਤਾ ਤੋਂ ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੇ ਕਈ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ, ਜੋ ਕਿ ਮਲਟੀ-ਵੇਰੀਐਂਟ ਸਟੋਰੇਜ ਦੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਇੱਕ ਗ੍ਰਾਫ ਮਾਡਲ ਦੇ ਅਧਾਰ ਤੇ ਮਲਟੀ-ਮਾਡਲ ਡੀ.ਬੀ.ਐਮ.ਐਸ.

ਧਿਆਨ ਦੇਣ ਯੋਗ ਤੱਥ ਇਹ ਹੈ ਕਿ ਮਾਰਕੀਟ ਵਿੱਚ ਅਜੇ ਤੱਕ ਕੋਈ ਬਹੁ-ਮਾਡਲ DBMS ਨਹੀਂ ਹਨ ਜੋ ਇੱਕ ਗ੍ਰਾਫ ਮਾਡਲ 'ਤੇ ਅਧਾਰਤ ਹਨ (ਇੱਕੋ ਸਮੇਂ ਦੇ ਦੋ ਗ੍ਰਾਫ ਮਾਡਲਾਂ ਲਈ ਮਲਟੀ-ਮਾਡਲ ਸਮਰਥਨ ਨੂੰ ਛੱਡ ਕੇ: RDF ਅਤੇ LPG; ਇਸ ਵਿੱਚ ਦੇਖੋ ਪਿਛਲੇ ਪ੍ਰਕਾਸ਼ਨ). ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਮੁਸ਼ਕਲਾਂ ਕਿਸੇ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਦੀ ਬਜਾਏ ਗ੍ਰਾਫ ਮਾਡਲ ਦੇ ਸਿਖਰ 'ਤੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ।

ਗ੍ਰਾਫ ਮਾਡਲ ਦੇ ਸਿਖਰ 'ਤੇ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਮਾਡਲ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ ਦੇ ਸਵਾਲ ਨੂੰ ਬਾਅਦ ਦੇ ਗਠਨ ਦੇ ਦੌਰਾਨ ਵੀ ਵਿਚਾਰਿਆ ਗਿਆ ਸੀ. ਕਿਵੇਂ ਬੋਲਿਆਉਦਾਹਰਨ ਲਈ ਡੇਵਿਡ ਮੈਕਗਵਰਨ:

ਗ੍ਰਾਫ ਪਹੁੰਚ ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ ਜੋ ਇੱਕ ਗ੍ਰਾਫ ਡੇਟਾਬੇਸ ਉੱਤੇ ਇੱਕ ਲੇਅਰ (ਉਦਾਹਰਨ ਲਈ, ਉਚਿਤ ਇੰਡੈਕਸਿੰਗ ਦੁਆਰਾ) ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜੋ (1) ਆਮ ਕੁੰਜੀ ਮੁੱਲ ਜੋੜਿਆਂ ਤੋਂ ਟੂਪਲਾਂ ਦੀ ਰਿਕਵਰੀ ਅਤੇ (2) ਸਮੂਹਾਂ ਦੇ ਨਾਲ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਦ੍ਰਿਸ਼ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਸਬੰਧ ਕਿਸਮ ਦੁਆਰਾ tuples.

ਗ੍ਰਾਫ ਮਾਡਲ ਦੇ ਸਿਖਰ 'ਤੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ:

• ਇੱਕ JSON ਐਰੇ ਦੇ ਤੱਤਾਂ ਨੂੰ ਕ੍ਰਮਬੱਧ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਗ੍ਰਾਫ ਦੇ ਇੱਕ ਕਿਨਾਰੇ ਦੇ ਸਿਰੇ ਤੋਂ ਨਿਕਲਣ ਵਾਲੇ ਤੱਤ ਨਹੀਂ ਹਨ;
• ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਵਿੱਚ ਡਾਟਾ ਆਮ ਤੌਰ 'ਤੇ ਅਸਧਾਰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਤੁਸੀਂ ਅਜੇ ਵੀ ਉਸੇ ਏਮਬੈਡਡ ਦਸਤਾਵੇਜ਼ ਦੀਆਂ ਕਈ ਕਾਪੀਆਂ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਉਪ-ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਪਛਾਣਕਰਤਾ ਨਹੀਂ ਹੁੰਦੇ ਹਨ;
• ਦੂਜੇ ਪਾਸੇ, ਦਸਤਾਵੇਜ਼ DBMSs ਦੀ ਵਿਚਾਰਧਾਰਾ ਇਹ ਹੈ ਕਿ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ-ਕੀਤੇ "ਏਗਰੀਗੇਟ" ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰ ਵਾਰ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਮੁਕੰਮਲ ਦਸਤਾਵੇਜ਼ ਦੇ ਅਨੁਸਾਰੀ ਇੱਕ ਸਬਗ੍ਰਾਫ ਨੂੰ ਜਲਦੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ ਗ੍ਰਾਫ ਮਾਡਲ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵਿਗਿਆਪਨ

ਲੇਖ ਦਾ ਲੇਖਕ ਨਾਈਟ੍ਰੋਸਬੇਸ ਡੀਬੀਐਮਐਸ ਦੇ ਵਿਕਾਸ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਜਿਸਦਾ ਅੰਦਰੂਨੀ ਮਾਡਲ ਗ੍ਰਾਫ ਹੈ, ਅਤੇ ਬਾਹਰੀ ਮਾਡਲ - ਰਿਲੇਸ਼ਨਲ ਅਤੇ ਦਸਤਾਵੇਜ਼ - ਇਸਦੇ ਪ੍ਰਤੀਨਿਧਤਾ ਹਨ. ਸਾਰੇ ਮਾਡਲ ਬਰਾਬਰ ਹਨ: ਲਗਭਗ ਕੋਈ ਵੀ ਡੇਟਾ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਇੱਕ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ ਜੋ ਇਸਦੇ ਲਈ ਕੁਦਰਤੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਿਸੇ ਵੀ ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਡੇਟਾ ਨੂੰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਪਰਿਵਰਤਨ ਅੰਦਰੂਨੀ ਮਾਡਲ ਵਿੱਚ ਪ੍ਰਤੀਬਿੰਬਿਤ ਹੋਣਗੇ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਹੋਰ ਵਿਚਾਰਾਂ ਵਿੱਚ.

ਮੈਂ ਉਮੀਦ ਨਾਲ ਵਰਣਨ ਕਰਾਂਗਾ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਲੇਖਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਨਾਈਟ੍ਰੋਸਬੇਸ ਵਿੱਚ ਮਾਡਲ ਮੈਚਿੰਗ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

ਸਿੱਟਾ

ਮੈਂ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਬਹੁ-ਮਾਡਲਿੰਗ ਕੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਦੀ ਆਮ ਰੂਪਰੇਖਾ ਪਾਠਕ ਲਈ ਘੱਟ ਜਾਂ ਘੱਟ ਸਪੱਸ਼ਟ ਹੋ ਗਈ ਹੈ. ਮਲਟੀ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ ਕਾਫ਼ੀ ਵੱਖਰੇ ਹਨ, ਅਤੇ "ਮਲਟੀ-ਮਾਡਲ ਸਪੋਰਟ" ਵੱਖਰੇ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ। ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਹਰੇਕ ਖਾਸ ਕੇਸ ਵਿੱਚ "ਮਲਟੀ-ਮਾਡਲ" ਕੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣਾ ਲਾਭਦਾਇਕ ਹੈ:

1. ਕੀ ਅਸੀਂ ਰਵਾਇਤੀ ਮਾਡਲਾਂ ਜਾਂ ਕਿਸੇ ਕਿਸਮ ਦੇ "ਹਾਈਬ੍ਰਿਡ" ਮਾਡਲ ਦਾ ਸਮਰਥਨ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ?
2. ਕੀ ਮਾਡਲ "ਬਰਾਬਰ" ਹਨ, ਜਾਂ ਕੀ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੂਜਿਆਂ ਦਾ ਵਿਸ਼ਾ ਹੈ?
3. ਕੀ ਮਾਡਲ ਇੱਕ ਦੂਜੇ ਪ੍ਰਤੀ "ਉਦਾਸੀਨ" ਹਨ? ਕੀ ਇੱਕ ਮਾਡਲ ਵਿੱਚ ਲਿਖਿਆ ਡੇਟਾ ਦੂਜੇ ਵਿੱਚ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਓਵਰਰਾਈਟ ਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?

ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਮਲਟੀ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ ਦੀ ਸਾਰਥਕਤਾ ਬਾਰੇ ਸਵਾਲ ਦਾ ਪਹਿਲਾਂ ਹੀ ਸਕਾਰਾਤਮਕ ਜਵਾਬ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਦਿਲਚਸਪ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਆਉਣ ਵਾਲੇ ਸਮੇਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀਆਂ ਕਿਹੜੀਆਂ ਕਿਸਮਾਂ ਦੀ ਮੰਗ ਵਧੇਰੇ ਹੋਵੇਗੀ. ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਬਹੁ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ ਜੋ ਰਵਾਇਤੀ ਮਾਡਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਰਿਲੇਸ਼ਨਲ, ਵਧੇਰੇ ਮੰਗ ਵਿੱਚ ਹੋਣਗੇ; ਬਹੁ-ਮਾਡਲ ਡੀਬੀਐਮਐਸ ਦੀ ਪ੍ਰਸਿੱਧੀ, ਨਵੇਂ ਮਾਡਲਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਵੱਖ-ਵੱਖ ਪਰੰਪਰਾਗਤ ਲੋਕਾਂ ਦੇ ਫਾਇਦਿਆਂ ਨੂੰ ਜੋੜਦੇ ਹਨ, ਬਹੁਤ ਦੂਰ ਭਵਿੱਖ ਦੀ ਗੱਲ ਹੈ।

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਸੀਂ ਮਲਟੀ-ਮਾਡਲ DBMS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ?

• ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਅਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ DBMS ਅਤੇ ਇੱਕ ਮਾਡਲ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਾਂ

• ਅਸੀਂ ਰਵਾਇਤੀ DBMSs ਦੀਆਂ ਬਹੁ-ਮਾਡਲ ਸਮਰੱਥਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

• ਅਸੀਂ ਪੌਲੀਗਲੋਟ ਨਿਰੰਤਰਤਾ ਦਾ ਅਭਿਆਸ ਕਰਦੇ ਹਾਂ

• ਅਸੀਂ ਨਵੇਂ ਮਲਟੀ-ਮਾਡਲ DBMS (Arango, Orient, CosmosDB) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

19 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਪਾਈ। 4 ਉਪਭੋਗਤਾ ਪਰਹੇਜ਼ ਰਹੇ।

ਸਰੋਤ: www.habr.com