Steem Data Services (SDS) / Update Notice / Version 0.1.7b

moecki (71) 3 years ago

Cool! Danke für deine Arbeit! 👍

New API Module post_tags_api

Die API ist schon sehr interessant. Das erspart mir das Durchlaufen von Posts. Bin gespannt, welche Methoden du da noch einbaust. TagsByCommunity und TagsByAuthor wären sehr nützlich für eine Community- und Autorenseite.

I worked really hard on this one to get the database size as small as possible.

Würde mich schon interessieren, wie du das gemacht hast. Könnte aber auch verstehen, wenn du hier nicht alle deine Algorithmen offenbaren möchtest.
Bedeutet das, dass du für jede API eine eigene Datenbank führst, die mit jedem Block aktualisiert wird?

$3.43

steemchiller (74) 3 years ago

TagsByCommunity und TagsByAuthor wären sehr nützlich für eine Community- und Autorenseite.

Da sich die Version noch in der Testphase befindet und ich aufgrund eines festgestellten Bugs heute sowieso einen kompletten 're-parse' starten muss, bevor sie in Produktion gehen kann, werde ich bei der Gelegenheit die post_tags_api noch etwas erweitern. Mehr Details dazu demnächst ;)

Bedeutet das, dass du für jede API eine eigene Datenbank führst, die mit jedem Block aktualisiert wird?

Ja, der Parser durchläuft die Blöcke und ruft entsprechende Events in den über die Config aktivierten Modulen auf (soweit das jeweile Modul nicht bereits bei einer höheren Blocknummer ist). Die Module können natürlich auch untereinander verknüpft werden, um Daten anderer APIs direkt abrufen zu können.

Jedes Parser-Modul verwendet normalerweise mindestens eine eigene Datenbank, die aber auch untereinander verknüpft (attached) werden können. Über die Config kann man auch festlegen, dass eine Datenbank für mehrere oder sogar alle Module verwendet werden soll, aber das würde ich aus Performance- und Wartungs-Gründen nicht empfehlen.

Es lassen sich auch Daten aus anderen Modulen direkt in SQL-Abfragen joinen, daher hat es deutlich mehr Vorteile die Datenbanken zu trennen und so unfragmentiert wie möglich zu speichern.

$0.20

moecki (71) 3 years ago

Die Aufteilung bringt zudem auch hinsichtlich der Verminderung der Redundanz sowie der im Notfall erforderlichen Wiederherstellung Vorteile. Allerdings wirst du dir dazu im Vorfeld wohl sehr viele Gedanken über die Art und Weise der Aufteilung und anschließender Verknüpfung (durch die SQL-Abfragen) gemacht haben. Dabei den Überblick zu behalten, ist nicht ohne.

Für den privaten Bereich habe ich ein paar mehr oder weniger komplexe Datenbanken erstellt und mit entsprechenden Abfragen und Codezeilen versehen. Insofern habe ich ungefähr eine Vorstellung davon, welchen Aufwand du mit der effizienten Speicherung der Daten der gesamten Blockchain hattest/hast.

Mehr Details dazu demnächst ;)

Bin gespannt. :-)
Heute hatte ich noch einen neuen Gedanken. Oftmals interessiert mich, bei welchen Posts neue Kommentare eingestellt wurden und würde danach gern sortieren, damit man auch neue Kommentare in älteren Posts nicht übersieht. Für jeden einzelnen Post bekäme man das mit den Replies auch raus. Allerdings ist dies für eine Post-Liste (z. B. aus der feeds_api) nicht ganz so "unaufwendig", da man erst zu jedem Post in der Liste die Replies abrufen müsste.
Wäre es anhand der Daten in deinen Datenbanken (unkompliziert) machbar, in der Response (z.B. nach feeds_api.getCommunityPostsByCreated) auch den Timestamp des letzten Kommentars zurückzugeben?

$2.54

steemchiller (74) 3 years ago

Wäre es anhand der Daten in deinen Datenbanken (unkompliziert) machbar, in der Response (z.B. nach feeds_api.getCommunityPostsByCreated) auch den Timestamp des letzten Kommentars zurückzugeben?

Mir gefällt deine Idee und ich denke, dass ich ein Feld last_reply in allen Feed-Listen für Root-Posts problemlos zurückgeben könnte. Wahrscheinlich wird das aber erstmal nur für neue Kommentare (Erstellungszeitpunkt) funktionieren, da ich sonst einen weiteren Index für das Feld updated (das den Zeitpunkt der letzten Änderung enthält) brauchen würde.

Ich schau mal, was ich da machen kann.

$0.15

moecki (71) 3 years ago

Das wäre doch sehr gut. Ich denke, es wäre nicht weiter tragisch, wenn es zunächst nur die neuen Kommentare funktioniert. Das wird sich dann ja nach und nach ändern.
Wenn du es eingebaut hast, wäre eine Info gut, damit ich weiß, wie das feld last_reply zurückgegeben wird, wenn es keine (oder keine neuen) Kommentare gibt.

$1.18

remlaps (74) last year

$ curl https://sds.steemworld.org/accounts_api/getVestingStats 2>/dev/null | jq -S '.result.defs.redfish'
{
  "count": 1815612,
  "from": 0,
  "to": 999999.999999
}

In SDS, is there any chance you could provide a way to get a look at the partitioning below "redfish" - maybe plankton up to 9,999 and tadpoles/guppies from 10,000 to 99,999 (or any other names would be fine...), then start redfish at 100k?

1.8 million is a lot of accounts. It would be nice to get easier visibility of movement within that partition. Also, it might be useful to have a new category at the top end of the scale to give the whales something to shoot for ;-)

Maybe something like this?

$3.12

3 votes

steemchiller (74) last year

Thanks for your ideas! Unfortunately, I can't change the categories for this upcoming version, but I agree that it would make sense.

I recently added a new method on the SDS dev server (sds0), which returns the account count for a specific VESTS range:
https://sds0.steemworld.org/describeMethod/accounts_api.getAccountCountByVESTSRange

For example, to get the number of accounts owning between 10,000 and 99,999 VESTS, you would call it like:
https://sds0.steemworld.org/accounts_api/getAccountCountByVESTSRange/own/10000-99999

$0.18

5 votes

khuc (46) last year

Hi steemchiller, sorry to bother you. I am a graduate student working on a research project. I found SDS very useful. I want to collect follow history data but I have some issues using the API. For example, https://sds0.steemworld.org/followers_api/getFollowHistory/steemchiller/1487426276-1688031076 only returns 2 records. It seems it does not return the complete records. Do you have any suggestions? Thank you!

$2.44

steemchiller (74) last year (edited)

Hi, with the current configuration of the followers_api module you won't be able to retrieve entries older than 3 months, because it is configured with store_history_days = 90 (config can be seen via https://sds0.steemworld.org/followers_api/getConfig).

So, currently there is no other way than traversing through all blocks' operations (for example with https://sds0.steemworld.org/blocks_api/getOpsInBlockRange/50000001-50000100/0/custom_json) and watch for custom_json ops with id = "follow". Not very efficient and will take a long time to go through the whole chain, but it would work.

$0.02

1 vote

moecki (71) 2 years ago (edited)

Hallo Chiller:
Eine kleine Fehlermeldung zur Steemworld von mir (EDIT: sind doch zwei :-) ):

Bei deinem Reward-Info-Tool auf https://steemworld.org/rewards-info passt irgendwas mit dem Date Range nicht. Obwohl ich ein gültiges Datum in die Felder eingetragen hatte, werden keine Rewards angezeigt.

Meine Eintragungen:

In der Konsole sieht man, dass folgende Abfrage versendet wird:

https://sds.steemworld.org/rewards_api/getRewards/author_reward/deutschunplugged/NaN-NaN/1000/0

Anscheinend passt die Umwandlung von Datum in Timestamp nicht so recht.

Bei der Berechnung der Beneficiaries ist etwas nicht nachvollziehbar:
Beim Spender (hier deutschunplugged) wird angezeigt:

Beim Empfänger (hier du-finanzbot) wird angezeigt:

Mir scheint, als wenn beim Empfänger von den SP- und STEEM-Beträgen noch einmal der Benef-%-Satz ermittelt wird.
Ich schätze, es liegt die Abfrage https://sds.steemworld.org/rewards_api/getComingBeneficiaryRewardsSummary/du-finanzbot zugrunde.
Da wird im Abschnitt "benef":{"stu":12.053,"sbd":0,"steem":23.908,"sp":23.908,"trx":23.908,"percent":25} der richtige Betrag zurückgegeben, aber bei den Summen in "sum_sp":11.954,"sum_trx":11.954,"sum_steem":11.954 stehen die geringeren Beträge.

$2.42

nadiaturrina (77) 3 years ago

Thanks for the latest update. You are very kind. Hopefully, Steemit will be more successful. The presence of steemworld.org really helps me in Steemit. We are waiting for the next update, @steemchiller
😊😊😊

$2.24

anyiglobal (63) 3 years ago

Thanks for the compliment

$0.00

moecki (71) 2 years ago

Hey, ich muss schon wieder hier einsteigen :-))
Seit gestern geben diverse Responses vom sds0 das Feld reply_count nicht mehr zurück. Das betrifft - soweit ich das jetzt feststellen konnte - alle Requests aus der content_search_api und feeds_api. Speziell aufgefallen ist dies bei getPostsByAuthorText und getCommunityPostsByCreated.

sds1 und sds sind nicht betroffen. Es sieht so aus, als wenn du an neuen Features arbeitest :-)
Es wäre aber schön, wenn das Feld erhalten bleibt.
Bin gerade dabei, mein Frontend für die Suche aufzubereiten, da michelangelo3 seinen Server (mit der Suchfunktion) abschalten möchte...

$1.67

3 votes

steemchiller (74) 2 years ago (edited)

Moin, ich habe das Feld gestern aus Kompatibilitätsgründen in children (wie es auch von der posts_api zurückgegeben wird) umbenannt. Dies ermöglicht es Entwicklern eine zentrale Logik für die Behandlung der Ergebnisse der posts_api und feeds_api zu haben, ohne zwischen verschiedenen Feldnamen wechseln zu müssen.

Ein paar neue Felder sind auch hinzugekommen, aber das werde ich alles demnächst in einem Post noch genauer erklären, bevor die neue Version auf sds und sds1 installiert wird. Für den Übergang empfehle ich dir, bis dahin erstmal fest auf sds0 zu gehen ;)

$0.43

moecki (71) 2 years ago

Da bin ich gespannt! :-)
Ich finde die Vereinheitlichung gut, da ich auch bisher eine Klasse für die "Aufbereitung" der Community-Post-Daten nutze. Für die Suche wären das je nach Suchbegriffen (Kombis aus Text, Tags und Accounts) unterschiedliche Requests, so dass dein Ansatz sehr gut passt. Das childrenhabe ich doch glatt übersehen...

Mir ist die Tage noch was anderes aufgefallen: Wir haben in der Community gemutete User, deren Post-Daten is_muted=0 enthalten. Das liegt sicher daran, dass der Beitrag selbst nicht (aktiv) gemutet wurde, sondern der User.
Ich nehme an, das ist so von dir beabsichtigt. Aktuell sehe ich hierfür nur die Möglichkeit, mit communities_api/getCommunityRolesdie gemuteten User abzurufen und abzugleichen. Oder siehst du eine Möglichkeit, dies mit den Community-Posts (aus der feeds_api) zurückzuliefern?

$2.98

steemchiller (74) 2 years ago

Oder siehst du eine Möglichkeit, dies mit den Community-Posts (aus der feeds_api) zurückzuliefern?

Es gibt ab der Version 0.1.8 (sds0) ein neues Feld author_role, das für gemutete User den Wert muted enthält. Damit könntest du das also jetzt schon lösen.

Trotzdem finde ich die Idee, ein extra Feld wie is_author_muted zu haben, gar nicht mal so schlecht. Ich werde mal schauen, ob ich das noch problemlos in der Version hinzufügen kann...

$1.00

akmal1 (70) 3 years ago

You always release information that is very important for us to know the Steem Data Service. thank you very much for providing more information regarding Steem Data Services (SDS) / Update Notice / Version 0.1.7b .

$1.60

msharif (79) 3 years ago

I always appreciate your work. Thank you for this.

$1.54

endersontowers (68) 3 years ago

You are doing an excellent job, you will see that all hard work pays off, congratulations on the upcoming steemit sds updates.

$1.49

artist1111 (76) 3 years ago (edited)

$0.00

ubongudofot (79) 3 years ago

These are great updates sir and i believe with this new upgrades and feautures, SDS would be a better working interface.

Thank you for this again, you are always doing a great Job which is very noticeably and well appreciated and i see no reason why i shouldnt vote for you.

I voted for you as a witness some weeks ago😊.

$1.48