Атрыманне вялікіх радкоў з SQL Azure - але куды ісці? Сталы, Blob ці нешта накшталт MongoDB?

Я прачытаў шмат параўнанняў паміж Azure Table/Blob/захоўваннем SQL, і я думаю, што ў мяне ёсць добрае разуменне ўсіх тых, ... але ўсё ж, я не ўпэўнены, куды ісці для маіх канкрэтных патрэбаў. Можа быць, хто-то з вопытам працы ў падобных сітуацыях і ў стане зрабіць рэкамендацыю.

<�Моцны> Што ў мяне ёсць

SQL-Azure БД, якая захоўвае артыкулы ў сырам HTML ўнутры калоны VARCHAR (макс). Кожны радок мае шмат слупкоў метададзеных і мноства індэксаў для лёгкага выканання запытаў. Табліца змяшчае шмат спасылак на карыстальнік, падпіскі, тэг і многія іншыя - так SQL DB будзе заўсёды неабходны для майго праекта.

<�Моцны> У чым праблема

У мяне ўжо ёсць каля 500 000 артыкулаў у гэтай табліцы, і я чакаю, што гэта расці мільёнаў артыкулаў у год. Змест HTML Кожны артыкул можа быць дзе-небудзь паміж некалькімі КБ і 1 МБ або, у вельмі рэдкіх выпадках, памерам больш за 1 МБ.

Узнікаюць дзве праблемы: у Azure SQL захоўвання каштуе дорага, а раней, чым пазней я застрэліцца ў галаву з выдаткамі на захоўванне гэтага. Акрамя таго, я ўдарыў GB DB гранiчнага памеру 150 таксама некалькі раней, чым пазней. Гэтыя 500000 артыкулаў ужо спажываюць 1,6 GB DB прасторы ў цяперашні час.

<�Моцны> Тое, што я хачу

Гэта ясна тыя, змест HTML павінен выйсці з БД SQL. У той час як сама табліца артыкула павінна заставацца для далучэння яго да карыстальнікаў, падпіска, тэгах і шмат чаго іншага для хуткага рэляцыйную адкрыцця неабходных артыкулаў, па меншай меры, Colum, які змяшчае кантэнт HTML можа быць перададзена на больш танныя прылады захоўвання.

<�Моцны> На першы погляд, Azure захоўвання Табліца здаецца, што ідэальна падыходзіць

Тэрабайт дадзеных у адзін вялікім стале для вельмі танных коштаў і хуткіх запытаў - гучыць ідэальна, каб мець асмаліць Табліцу захоўванне табліцы, утрымліваўся змест артыкула ў якасці дадатку да БД SQL.

Але прачытаўшы параўнання тут паказвае, што гэта не можа быць нават варыянт: 64 КБ на калонцы хапіла б на 98% з маіх артыкулаў, але ёсць і тыя 2% злева, дзе для некаторых асобных артыкулаў нават цэлыя 1 МБ мяжы радкі можа не дастаткова.

<�Моцны> захоўвання Blob гучыць зусім няправільна, але ...

Такім чынам, ёсць толькі адзін варыянт на Блакітным злева: Blobs. Цяпер, гэта можа быць не так няправільна, як гэта гучыць. У большасці выпадкаў, я павінен быў бы ўтрыманне толькі адным артыкуле адразу. Гэта павінна працаваць нармальна і досыць хутка з захоўваннем Blob.

Але ў мяне ёсць пытанні, дзе я павінен быў бы 50, 100 ці нават больш радкоў адразу ЛІКУ нават змест. Такім чынам, я павінен быў бы выканаць запыт SQL для здабывання патрэбных артыкулаў, а затым выбарак кожнага артыкула з сховішчы Blob. У мяне няма досведу працы з гэтым, але я не магу паверыць, што я змагу застацца ў мілісекундах прамежку часу для запытаў пры выкананні гэтага. І запыты, якія адымаюць некалькі секунд не зьяўляюцца абсалютным не вартыя для майго праекта.

Так яно і не падобна, каб быць прыдатным рашэннем.

<�Моцны> Ці павінен я выглядаць як хлопец з планам?

Прынамсі, у мяне ёсць нешта накшталт плана. Я думаў толькі пра «экспарце» адпаведныя запісы ў SQL табліцу для захоўвання і/або Blob Storage.

Something like "as long as the content is < 64 KB export it to table storage, else keep it in the SQL table (or even export this single XL record into BLOB storage)"

Гэта можа працаваць досыць добра. Але гэта робіць рэчы складанымі і можа быць непатрэбнымі памылкамі.

<�Моцны> Тыя і іншыя варыянты

Ёсць некаторыя іншыя NoSQL БД як MongoDB і CouchDB, якія, здаецца, каб лепш адпавядаць маім патрэбам (прынамсі, з майго наіўнай пункту гледжання, як нехта, хто толькі што прачытаў спецыфікацыі на паперы, у мяне няма досведу працы з імі). Але яны патрабуюць ўласнай хостынгу, некаторыя рэчы, я хацеў бы, каб выйсці з яго шляху, калі гэта магчыма. Я на Azure, каб рабіць як трэба з пункту гледжання самастойнай хостынг сервераў і сэрвісаў.

<�Моцны> Няўжо вы сапраўды чыталі да тых часоў тут?

Тады дзякуй вам вялікі за вашу каштоўнае час і думаць пра свае праблемы :)

Любыя прапановы будуць з падзякай. Як вы бачыце, у мяне ёсць свае ідэі і планы, але нішто не параўнаецца вопыт ад каго-небудзь, хто ішоў па дарозе, перш чым :)

дзякуй, Бернхард

7
Не маглі б вы рэалізаваць схему кэшавання, якія зрабілі б Blobs выконваць дастаткова добра? Магчыма, кэшаваць іх на лакальным дыску для захоўвання віртуальнай машыны?
дададзена аўтар Brian Reischl, крыніца
Я думаў, вы маглі б выкарыстоўваць лакальнае сховішча (гэта значыць, дыск) на віртуальных машынах, а не АЗП. Нават даволі маламагутныя віртуальныя машыны могуць мець шмат дыскаў, напрыклад, невялікая вэб-ролю можа мець 224GB лакальнага захоўвання дыска. msdn.microsoft.com/en-us/library/windowsazure/dn197896. ASPX Але гэта часовае захоўванне, таму было б атрымаць вычысьцілі і павінны быць адноўлены пры перазапуску VM.
дададзена аўтар Brian Reischl, крыніца
Гэта можа быць ідэя - як у цэлым, найбольш часта выкарыстоўваюцца прадметы будуць тыя, за апошнія 30 дзён. Гэта пытанне намаганняў супраць выгады і пытанне, як дорага, з пункту гледжання аператыўнай памяці, дастаткова кэшаванне было б як затраты, напрыклад, у Azure, якія прапануюць дастатковы аб'ём аператыўнай памяці будзе (магчыма) таксама можа быць дарагім. Але дзякуй за ўваход, defenitely тое, што я павінен прымаць пад увагу.
дададзена аўтар Bernhard Koenig, крыніца

8 адказы

Я падпісаўся проста выключна, каб дапамагчы з гэтым пытаннем. У мінулым, я знайшоў карысныя адказы на мае праблемы ад Stackoverflow - дзякуй супольнасці - так я думаў, што гэта будзе проста быць справядлівым (магчыма, справядліва з'яўляецца прыніжэнне), каб паспрабаваць даць нешта з гэтым пытаннем, як ён падае на маім завулку ,

Карацей кажучы, у той час як з улікам усіх фактараў, названых ў пытанні, захоўванне табліца можа быць самы лепшы варыянт - IIF вы можаце правільна ацаніць здзелкі у месяц: добры артыкул па гэтым . Вы можаце вырашыць два абмежаванні, якія вы згадалі, радкі і слупкі, мяжа, расшчапленнем (просты метад тэксту або серыялізацыі) дакумент/HTML/дадзеныя. не гаварыць ад вопыту з 40 Гб + дадзеныя, якія захоўваюцца ў табліцы захоўвання, дзе часта наша дадатак здабывае больш за 10 радкоў на кожнай старонцы візіту ў мілісекундах - не аргумент тут! Калі вам трэба 50+ радкі ў разы, вы глядзіце на нізкія адназначныя лічбах секунд (ы), або вы можаце зрабіць іх паралельна (і далей шляхам падзелу дадзеных у розных частках), або ў якой-то асінхроннай модзе. Ці чытаць прапанаваў кэшаванне некалькіх узроўняў ніжэй.

Крыху больш падрабязна. Я паспрабаваў з SQL Azure, Blob (абедзве старонкі і блок), і табліца захоўвання. Я не магу гаварыць за Монго DB, так як, часткова па прычынах, ужо згаданыя тут, я не хачу ісці па гэтым шляху.

  • Табліца захоўвання хутка; ў дыяпазоне 20-50 мілісекунд, ці нават хутчэй, часам (у залежнасці, напрыклад, у тым жа самым цэнтры дадзеных я бачыў, што гэта прайшло, як нізка як 10 мілісекунд), пры запыце з перагародкай і ключом радка. Вы таксама можаце дадаткова мець некалькі раздзелаў, у пэўным сэнсе на аснове вашых дадзеных і вашых ведаў пра яго.
  • Гэта шалі лепш, з пункту гледжання ГБ, але не здзелкі
  • Абмежаванні
  • радкоў і слупкоў, якія вы згадалі ў цяжар, ​​пагадзіліся, але не паказваць коркі. Я напісаў сваё ўласнае рашэнне, каб падзяліць аб'екты, вы можаце занадта лёгка, ці вы можаце ўбачыць гэта ўжо складзенае-рашэнне (не вырашае усю праблему, але гэта добры старт): https://code.google.com/p/lokad-cloud/wiki/FatEntities
  • Акрамя таго, неабходна мець на выглядзе, што загрузка дадзеных у таблічным захоўванне займае шмат часу, нават калі дазаванне аб'ектаў з-за іншыя абмежаванні (г.зн. памер запыту менш за 4 МБ, выходны трафік, і г.д.).

Але выкарыстанне выключна толькі TableStorage не можа быць лепшым рашэннем (думаючы пра рост і эканомікі). Лепшае рашэнне, што мы ў канчатковым выніку рэалізацыі, які выкарыстоўваецца шматузроўневую кэшавання/захоўвання, пачынаючы ад статычных класаў, Azure аснове роляў кэша, табліца захоўвання, і блакаваць Blobs. Давайце называць гэта, у мэтах лёгкачытэльнасць, ўзроўню 1A, 1B, 2 і 3 адпаведна. Выкарыстоўваючы гэты падыход, мы выкарыстоўваем сярэднюю адзін асобнік (2 Ядры працэсара і 3,5 Гб аператыўнай памяці - мой ноўтбук мае больш высокую прадукцыйнасць), і здольныя апрацоўваць/запыту/Ацэнка 100GB + дадзеных у секундах (95% выпадкаў ва ўзросце да 1 секунды ). Я лічу, што гэта даволі ўражвае, улічваючы, што мы правяраем усе "артыкулы" перад адлюстраваннем іх (4 + мільёнаў «артыкулы»). Па-першае, гэта складана, і можа ці не можа быць магчыма ў вашым выпадку. У мяне няма дастатковых ведаў аб дадзеных і іх выкарыстання запытаў/апрацоўкі, але калі вы можаце знайсці спосаб арганізацыі даных добра гэта можа быць ідэальным. Зраблю здагадку: гэта гучыць, як вы спрабуеце шукаць праз і знайсці адпаведныя артыкулы, дадзеныя некаторую інфармацыю аб карыстальніку і некаторых тэгаў (варыянт агрэгатар навін, магчыма, толькі што здагадка для гэтага). Гэтая здагадка зроблена дзеля ілюстрацыі прапановы, так што нават калі не правільна, я спадзяюся, што гэта дапаможа або выклікаць новыя ідэі аб тым, як гэта можна было б прыняць.

Level 1A data. Identify and add key entities or its properties in a static class (periodically, depending on how you foresee updates). Say we identify user preferences (e.g., demographics and interest, etc) and tags (tech, politics, sports, etc). This will be used to retrieve quickly who the user is, his/her preferences, and any tags. Think of these as key/value pair; for instance key being a tag, and its value being a list of article IDs, or a range of it. This solves a small piece of a problem, and that is: given a set of keys (user pref, tags, etc) what articles are we interested in! This data should be small in size, if organized properly (e.g., instead of storing article path, you can only store a number). *Note: the problem with data persistence in a static class is that application pool in Azure, by default, resets every 20 minutes or so of inactivity, thus your data in the static class is not persistent any longer - also sharing them across instances (if you have more than 1) can become a burden. Welcome level 1B to the rescue.

Leval 1B data A solution we used, is to keep layer 1A data in a Azure Cache, for its sole purpose to re-populate the static entity when and if needed. Level 1B data solves this problem. Also, if you face issues with application pool reset timing, you can change that programmatically. So level 1A and 1B have the same data, but one is faster than the other (close enough analogy: CPU Cache and RAM).

Discussing level 1A and 1B a bit One may point out that it is an overkill to use a static class and cache, since it uses more memory. But, the problem we found in practice, is that, first it is faster with static. Second, in cache there are some limitations (ie., 8 MB per object). With big data, that is a small limit. By keeping data in a static class one can have larger than 8 MB objects, and store them in cache by splitting them (i.e., currently we have over 40 splits). BTW please vote to increase this limit in the next release of azure, thank you! Here is the link: www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/3223557-azure-preview-cache-increase-max-item-size

Level 2 data Once we get the values from the key/value entity (level 1A), we use the value to retrieve the data in Table Storage. The value should tell you what partition and Row Key you need. Problem being solved here: you only query those rows relevant to the user/search context. As you can see now, having level 1A data is to minimize row querying from table storage.

Level 3 data Table storage data can hold a summary of your articles, or the first paragraph, or something of that nature. When it is needed to show the whole article, you will get it from Blob. Table storage, should also have a column that uniquely identifies the full article in blob. In blob you may organize the data in the following manner:

  1. Падзяліць кожны артыкул у асобных файлах.
  2. Група п артыкулы ў адным файле.
  3. Група усе артыкулы ў адным файле (не рэкамендуецца, хоць і не так дрэнна, як першае ўражанне можна атрымаць).

За 1-ы варыянт вы б захоўваць у памяці табліцы, шлях артыкула, то проста вазьміце яго прама з Blob. З-за названых вышэй узроўняў, калі вам трэба прачытаць толькі некалькі поўных артыкулаў тут.

Для 2-й і 3-й варыянт вы б захоўваць у памяці табліцы, шлях да файла і пачатковай і канчатковай пазіцыі, адкуль чытаць і куды спыніць чытанне, выкарыстоўваючы шукаць.

Вось прыклад кода ў C #:

YourBlobClientWithReferenceToTheFile.Seek(TableStorageData.start, SeekOrigin.Begin);
        int numBytesToRead = (int)TableStorageData.end - (int)TableStorageData.start;
        int numBytesRead = 0;

        while (numBytesToRead > 0)
        {

          int n = YourBlobClientWithReferenceToTheFile.Read(bytes,numBytesRead,numBytesToRead);
            if (n == 0)
                break;
            numBytesRead += n;
            numBytesToRead -= n;
        }

Я спадзяюся, што гэта не ператворыцца ў кнігу, і спадзяюся, што гэта было карысна. Не саромейцеся звязацца са мной, калі ў вас ёсць дадатковыя пытанні ці заўвагі. Дзякуй!

7
дададзена
Прывітанне Merg! Вялікі дзякуй за вас намаганняў і вашы карысныя каментары! Гэта выдатна пачуць водгукі & вопыт ад каго-то, што вырашыць вельмі падобныя пытанні. Я проста апублікаваць зараз, каб сказаць дзякуй, я павінен буду думаць пра гэта і эксперыментаваць з ім і можа вярнуцца да вашага прапанове для задаваць вам пытанні пазней :)
дададзена аўтар Bernhard Koenig, крыніца
Вы вельмі гасцінна і ўдачы з вашым праектам!
дададзена аўтар Merg, крыніца

Належнае захаванне для файла з'яўляецца блобо. Але калі ваш запыт павінен вяртаць дзясяткі згусткаў ў той жа час, гэта будзе занадта павольна, як вы паказваючы. Такім чынам, вы можаце выкарыстоўваць гібрыдны падыход: выкарыстоўваць Azure Tables 98% вашых дадзеных, і калі ён занадта вялікі, выкарыстоўвайце Blob замест і захоўваць Blob URI ў табліцы.

Акрамя таго, вы сціскае кантэнт на ўсіх? Я ўпэўнены, што будзе.

2
дададзена
Я не бачу, што змест артыкула ў выглядзе файлаў - гэта хутчэй ўтрыманне, якое таксама можна разглядаць як або змясціць у файл для захоўвання. Але ў першую чаргу гэта ўтрыманне ў DataRow. Ваш suggestet apporach добра гучыць у цэлым, і я згадаў пра гэта ў маім пытанні як-то я лічу, але я баюся, што складанасць і непрадбачаная прадукцыйнасць запытаў у залежнасці ад спалучэння запытаў SQL/Table/Blob. Але гэта можа быць маім лепшым выбарам пры выкарыстанні PaaS-Azure-паслугі.
дададзена аўтар Bernhard Koenig, крыніца

You could use MongoDB's GridFS feature: http://docs.mongodb.org/manual/core/gridfs/

Ён разбівае дадзеныя ў 256k кавалкаў па змаўчанні (наладжваецца да 16Мб) і дазваляе выкарыстоўваць sharded базы дадзеных у якасці файлавай сістэмы, які можна выкарыстоўваць для захоўвання і здабывання файлаў. Калі файл больш, чым памер порцыі, вадзіцелі Монго DB апрацоўваць расколваецца/паўторнай зборкі дадзеных, калі файл павінен быць адноўлены. Для таго, каб дадаць дадатковае дыскавая прастора, проста дадайце дадатковыя чарапкі.

Варта мець на ўвазе, аднак, што толькі некаторыя драйверы MongoDB падтрымліваюць гэта, і гэта ўмоўнасць драйвер, а не асаблівасць сервера, які дазваляе гэта паводзіны.

1
дададзена
Дзякуючы Тайлер, безумоўна, варта паглядзець. У той час як я думаю, што падтрымлівае дакумент у 16 ​​МБ BSON будзе дастаткова для мяне. На самай справе, я думаю, што 5 МБ будзе цалкам етично мне трэба падтрымліваць. Ці ёсць у MongoDB абмежаванне як Azure Table Storage, што ResultSet не можа быць больш, чым 4 МБ? Гэта было б толькі спыніць усю працу.
дададзена аўтар Bernhard Koenig, крыніца

Некалькі каментароў:

  • Што вы можаце зрабіць, гэта <�моцны> ЗАЎСЁДЫ крама HTML ўтрыманне ў сховішча вялікіх двайковых аб'ектаў і захоўваць URL блоб ў ў памяці табліцы. Я асабіста не падабаецца ідэя захоўвання дадзеных ўмоўна, г.зн. калі ўтрыманне HTML-файла больш чым 64 KB толькі затым захаваць яго ў сховішча вялікіх двайковых аб'ектаў у адваротным выпадку выкарыстоўваць для захоўвання табліцы. Іншая перавага вы атрымаеце з гэтага падыходу заключаецца ў тым, што вы можаце запытаць дадзеныя. Калі вы захоўваеце ўсе ў сховішча вялікіх двайковых аб'ектаў, вы страціце запытваючы магчымасці.
  • Што тычыцца выкарыстання іншых крам NoSQL, то толькі праблема, якую я бачу з імі ў тым, што яны першапачаткова не падтрымліваюцца на Windows Azure, такім чынам, вы будзеце адказныя за кіраванне імі, а таксама.
1
дададзена
Так, я таксама хачу, каб пазбегнуць ўмоўна захоўваемых дадзеных да таго часу, пакуль існуе яшчэ адзін варыянт. Праблема з захоўваннем Blob ў тым, што я бачу праблемы з прадукцыйнасцю запытаў некалькі сотняў элементаў адначасова (у параўнанні з больш запытаў-арыентаваных сховішчаў, такіх як табліцы захоўвання і SQL Azure), але, як сказаў Дэвід, гэта можа быць не так дрэнна, як я думаю, што гэта з пункту гледжання прадукцыйнасці. Прыйдзецца праверыць. Тое, што я хачу рабіць у любым выпадку, заўсёды маюць метададзеныя кантэнту ў маёй базе дадзеных SQL Azure, таму запыты будуць зробленыя там і спасылкі на BLOB (або табліца) запамінальныя элементы таксама будуць захаваны ў табліцы SQL Azure.
дададзена аўтар Bernhard Koenig, крыніца

Адна ідэя, што я павінен быў бы выкарыстаць CDN для захоўвання змест артыкула, і звязаць іх непасрэдна на баку кліента, а не які-небудзь мульты фазы, аперацыя атрымання дадзеных з SQL затым збіраецца ў якой-сховішча. Гэта было б нешта накшталт

http:////.html

Infact тое ж самае можна зрабіць з захоўваннем Blob таксама.

Перавага тут у тым, што гэта робіцца жахліва хутка.

Нязручнасць ў тым, што аспект бяспекі губляецца.

Нешта накшталт Shared Access Signature можа быць вывучана для забеспячэння бяспекі, але я не ўпэўнены, наколькі карысным было б для кліенцкіх злучэнняў.

1
дададзена
Мой дрэнны я пераблытаў паняцце, але асноўная ідэя тут у тым, каб ўстаўляць URL непасрэдна на баку кліента.
дададзена аўтар Chandermani, крыніца
CDN не з'яўляецца механізмам захоўвання: Гэта кэш краю звязаны з захоўвання вялікіх двайковых аб'ектаў.
дададзена аўтар David Makogon, крыніца
Гэта добрая ідэя, але гэта не дапаможа ў маім выпадку (бяспека не будзе вялікай праблемай, хоць тут). Прычына заключаецца ў тым, што неабходнасць вяртання мультыплікатара (50, 100, ...) артыкула адразу ў асноўным патрэбна для кліентаў сінхранізацыі, якія ўключаюць у сябе прыкладання для смартфонаў. Выпуск 100 HTTP-запытаў на смартфонах для атрымання кантэнту вельмі павольна з-за якая адсутнічае прадукцыйнасць працэсара гэтых прылады маюць, не кажучы ўжо, калі гэтыя прылады знаходзяцца ў раёнах з нізкім узроўнем ахопу. Адзінкавыя выклікі HTTP, якія вяртаюць больш дадзеных адразу ў сціснутай працы адказу значна, значна лепш у гэтым сцэнары. Дзякуй ў любым выпадку, вельмі добрая прапанова, тым не менш!
дададзена аўтар Bernhard Koenig, крыніца

Мае думкі з гэтай нагоды: ідучы MongoDB (або CouchDB) маршрут будзе ў канчатковым выніку каштаваць вам дадатковых Compute, як вам трэба запусціць некалькі сервераў (для забеспячэння высокай даступнасці). І ў залежнасці ад прадукцыйнасці, неабходнай, вы можаце ў канчатковым выніку працуе 2- ці 4-цэласных скрынь. Тры 4-цэласных скрынь будзе працаваць больш, чым вашыя выдаткі SQL DB (плюс то бок, кошт захоўвання, і MongoDB і г.д. адступіць свае дадзеныя ў Azure Blob для захоўвання duable).

Цяпер, як і для захоўвання вашых HTML у згусткі: гэта вельмі агульны шаблон, каб разгрузіць буйныя аб'екты ў сховішча вялікіх двайковых аб'ектаў. GETs павінна быць выканальна ў адным выкліку сховішчы вялікіх двайковых аб'ектаў (адной транзакцыі), асабліва з памерам файла, які вы згадалі. І вы не павінны атрымаць кожны блоб паслядоўна; Вы можаце скарыстацца TPL спампаваць некалькі згусткаў да экземпляра ролі паралельна.

Яшчэ адна рэч: Як вы карыстаецеся ўтрыманне? Калі вы струменевы ад вашых асобнікаў ролі, тое, што я сказаў пра TPL павінна працаваць добра. Калі ж, з другога боку, вы ін'екцыйныя HREF 's ў вашу старонку вываду, вы можаце проста паставіць блоб URL непасрэдна ў HTML-старонкі. І калі вы турбуецеся аб прыватнасці, зрабіць згусткі прыватных і генераваць кароткі-TTL «агульны доступ подпіс», які прадстаўляе доступ да акна невялікага часу (гэта дастасавальна толькі калі ўставіць URL аб'екта Blob-й у якую-небудзь іншы HTML-старонцы, ён не ўжываецца калі вы спампоўваеце да экземпляра ролі, а затым зрабіць што-то з ёй).

1
дададзена
Існавала шмат добрых адказана тут, якія дапамаглі мне, дзякуй усім! Я выбіраю Давидс адказ як адказ, як яго каментары былі найбольш карысныя для мяне ў цэлым.
дададзена аўтар Bernhard Koenig, крыніца
Дзякуючы Дэвід. Падобна Blobs б сапраўды быць альтэрнатывай, калі TPL выконвае дастаткова добра. Я павінен праверыць, але тое, што вы кажаце, выглядае шматабяцальным. Выкарыстанне Blobs я страціць магчымасці пошуку кантэнту (я ведаю, што я не згадаў гэта патрабаванне, але гэта тое, што лічыцца вельмі неабавязкова), так і іншы варыянт заключаецца ў выкарыстанні сціску для кантэнту, які будзе мець той жа недахоп, але будзе зрабіць табліцу для захоўвання зноў варыянт , Каб адказаць на ваша пытанне, я ў асноўным паток кантэнту для кліентаў, часам у выглядзе асобных элементаў, часам у спісах.
дададзена аўтар Bernhard Koenig, крыніца

вы не кажаце, але калі вы не сціскаць вашыя артыкулы, якія, верагодна, вырашае праблему, то проста выкарыстоўваць для захоўвання табліцы.

У адваротным выпадку проста выкарыстоўваць для захоўвання табліцы і выкарыстоўваць унікальны ключ раздзела для кожнага артыкула. Калі артыкул занадта вялікі пакласці яго ў 2 шэрагу, да таго часу, як вы запыт па ключы раздзелу вы атрымаеце абедзве радкі, а затым выкарыстоўваць ключ радкі ў якасці індэкса, паказваў, як вырабы адпавядаюць разам

0
дададзена
Дзякуючы Сэму. Сціск з'яўляецца варыянтам, Althought было б зрабіць пошук ўтрымання цяжка. Але гэтае патрабаванне я мог бы проста ўпасці, калі я атрымаць выгаду з магчымасці лёгкага і таннага захоўвання. Расшчапленне таксама будзе добрай ідэяй, але гэта робіць рэчы складаныя зноў (разам з лімітам 4 МБ у выніку запыту). Але гэта тое, што я павінен праверыць, таксама.
дададзена аўтар Bernhard Koenig, крыніца

Іншым варыянтам было б захоўваць вашыя файлы ў якасці VHD ладу ў сховішча вялікіх двайковых аб'ектаў. Вашы ролі могуць мантаваць VHD да іх файлавай сістэме і чытаць дадзеныя з яго.

Складанасць, здаецца, што толькі адна VM можа мець доступ для чытання/запісы на віртуальны жорсткі дыск чытаць. Астатнія могуць стварыць здымак і чытаць ад гэтага, але яны не будуць бачыць абнаўлення. У залежнасці ад таго, як часта вашы дадзеныя абнаўляюцца, якія маглі б працаваць. напрыклад, калі вы абнаўляеце дадзеныя ў добра вядомыя часы вы маглі б усе кліенты размантаваць, вазьміце новы здымак, і перамантаваць, каб атрымаць новыя дадзеныя.

Вы можаце таксама дзяліць віртуальны жорсткі дыск з дапамогай сумеснага выкарыстання SMB, як апісана ў гэтым MSDN блог . Гэта дазволіла б поўны доступ на чытанне/запіс, але можа быць трохі менш надзейным і крыху больш складана.

0
дададзена
Мантаванне VHD выявы як дыск з'яўляецца добрай ідэяй для састарэлых прыкладанняў, якія патрабуюць, каб тыпу доступу. Калі будаваць новае прыкладанне, яно мае ўсё менш сэнсу, а менавіта для кропкі вы крыкнуць, што гэта не маштабуецца (вы ў асноўным будзе падзелу дадзеных паміж некалькімі VHD, адной для кожнага асобніка ролі). Праблемы пагаршаюцца, калі канкрэтныя выпадкі перазагрузкі, у выніку чаго некаторыя дадзеныя недаступныя на працягу перыяду часу). Вы можаце наладзіць SMB з віртуальнай машынай, але я думаю, што гэта больш накладных выдаткаў, чым прамога доступу да згусткаў (і вы цяпер яшчэ адзін вылічальны асобнік працуе для SMB-сервера.
дададзена аўтар David Makogon, крыніца
І гэты сервер SMB, верагодна, спатрэбіцца больш, чым у малых, так як прапускная здольнасць складае 100 Мбіт на кожнае ядро. Вы не хочаце, каб сервер SMB, каб стаць вузкім месцам.
дададзена аўтар David Makogon, крыніца
Дзякуючы Браян. Але я не вельмі разумею, што вы думаеце, гэта фактычнае перавага ў параўнанні з простым выкарыстаннем асобных файлаў для кожнага элемента ў сховішча вялікіх двайковых аб'ектаў ... выкарыстоўваючы тэхніку, акрамя таго, што Дэвід ужо згадвалася, як бы гэтая хуткасць да запытваючы шмат артыкулаў адразу VS. класічнае захоўванне Blob?
дададзена аўтар Bernhard Koenig, крыніца